How to convert a string to a byte array in C#

1Encoding.UTF8.GetBytes and GetStringRecommended

Encoding.UTF8.GetBytes encodes every character and returns a new array. Encoding.UTF8.GetString does the reverse, either for the whole array or for a slice given as a start index and a byte count. ASCII characters take one byte each in UTF-8, and anything else takes two to four, so the byte count is often not the string's Length. For a constant, C# 11 added u8 literals, which the compiler encodes for you into a ReadOnlySpan<byte>.

using System.Text;

string text = "héllo, wörld";

// string -> byte[]: encode the characters as UTF-8
byte[] bytes = Encoding.UTF8.GetBytes(text);
Console.WriteLine($"{text.Length} chars -> {bytes.Length} bytes");
Console.WriteLine(string.Join(" ", bytes));
Console.WriteLine(Convert.ToHexString(bytes));

// byte[] -> string: decode with the same encoding
string back = Encoding.UTF8.GetString(bytes);
Console.WriteLine(back);
Console.WriteLine(back == text);

// Decode part of an array: start index and byte count
Console.WriteLine(Encoding.UTF8.GetString(bytes, 0, 6));

// ToString() on an array does not decode it
Console.WriteLine(bytes.ToString());

// C# 11+: a u8 literal is UTF-8 bytes, encoded at compile time
ReadOnlySpan<byte> greeting = "héllo"u8;
Console.WriteLine(greeting.Length);
Console.WriteLine(Encoding.UTF8.GetString(greeting));

Prints 12 chars -> 14 bytes: é and ö take two bytes each (195 169 and 195 182, or C3A9 and C3B6 in hex). Decoding gives back héllo, wörld and the comparison prints True. The slice prints héllo, because the first six bytes are five characters. Slice on character boundaries: a count that cuts a character in half decodes to a replacement character (section 5). Then System.Byte[], the type name, which is all ToString() on an array gives you. The u8 literal is 6 bytes and decodes to héllo. For a readable dump, Convert.ToHexString (.NET 5+) is the one-liner; see converting a byte array to a hex string.

2Other encodings: UTF-16, UTF-32, Latin-1 and ASCII

Every Encoding has the same GetBytes and GetString methods, so switching is one word. Use the one the other side expects: a file format, a protocol or a legacy system usually names it. The loop below encodes the same string with each built-in encoding and decodes it again, then decodes UTF-8 bytes with the wrong encodings to show what that looks like.

using System.Text;

string text = "Café €5";
Console.WriteLine($"{text.Length} chars");

Encoding[] encodings =
[
    Encoding.UTF8, Encoding.Unicode, Encoding.BigEndianUnicode,
    Encoding.UTF32, Encoding.Latin1, Encoding.ASCII,
];

foreach (Encoding enc in encodings)
{
    byte[] bytes = enc.GetBytes(text);
    string back = enc.GetString(bytes);
    Console.WriteLine($"{enc.WebName,-11} {bytes.Length,2} bytes -> {back}");
}

// Decoding with the wrong encoding garbles the text
byte[] utf8 = Encoding.UTF8.GetBytes("Café");
Console.WriteLine(Convert.ToHexString(utf8));
Console.WriteLine(Encoding.Latin1.GetString(utf8));
Console.WriteLine(Encoding.ASCII.GetString(utf8));

The 7-character string is 10 bytes in UTF-8, 14 in UTF-16 (Encoding.Unicode, little-endian, and Encoding.BigEndianUnicode) and 28 in UTF-32. Those four round-trip to Café €5. The two single-byte encodings don't: Latin-1 has no € and prints Café ?5, and ASCII stops at 127 and prints Caf? ?5. Neither throws; the encoder writes a ? and moves on, so the loss is silent. The last three lines are the classic mojibake: UTF-8 bytes 436166C3A9 read as Latin-1 give Café, and read as ASCII give Caf??. Encoding.Latin1 is .NET 5+; Windows code pages such as 1252 need a provider (see the FAQ).

3The raw bytes, without choosing an encoding

Sometimes you don't care what the bytes mean. You want a byte form of the string to hash, cache or store, and to get the exact same string back later. The string already has one: its UTF-16 code units in memory. MemoryMarshal.AsBytes(text.AsSpan()) (.NET Core 2.1+) views them as bytes without copying, and MemoryMarshal.Cast<byte, char> goes back. Older code copies the chars with Buffer.BlockCopy, which gives the same bytes.

using System.Runtime.InteropServices;
using System.Text;

string text = "Hi €";

// The string's own UTF-16 code units, viewed as bytes (no copy)
ReadOnlySpan<byte> raw = MemoryMarshal.AsBytes(text.AsSpan());
Console.WriteLine(Convert.ToHexString(raw));

// Copy into an array when an API wants byte[]
byte[] bytes = raw.ToArray();
Console.WriteLine(bytes.Length);

// The classic version of the same copy
byte[] copy = new byte[text.Length * sizeof(char)];
Buffer.BlockCopy(text.ToCharArray(), 0, copy, 0, copy.Length);
Console.WriteLine(copy.AsSpan().SequenceEqual(bytes));

// On little-endian hardware, that is exactly Encoding.Unicode
Console.WriteLine(BitConverter.IsLittleEndian);
Console.WriteLine(bytes.AsSpan().SequenceEqual(Encoding.Unicode.GetBytes(text)));

// And back: view the bytes as chars
string back = new string(MemoryMarshal.Cast<byte, char>(bytes));
Console.WriteLine(back);

// The one difference: a lone surrogate survives the raw copy,
// while an encoder replaces it
string broken = "a\uD800b";
Console.WriteLine(Convert.ToHexString(MemoryMarshal.AsBytes(broken.AsSpan())));
Console.WriteLine(Convert.ToHexString(Encoding.Unicode.GetBytes(broken)));
Console.WriteLine(Convert.ToHexString(Encoding.UTF8.GetBytes(broken)));

Prints 480069002000AC20: two bytes per char, low byte first, so € (U+20AC) is AC20. That is 8 bytes, the BlockCopy copy matches (True), and on a little-endian machine, which covers x64 and ARM64 as .NET runs on them, it is byte for byte Encoding.Unicode (True, True). Back comes Hi €. The difference shows up with a broken string: a lone surrogate D800 survives the raw view (610000D86200), while Encoding.Unicode swaps it for U+FFFD (6100FDFF6200) and UTF-8 writes that as EFBFBD. So the raw bytes always round-trip, but they depend on byte order and are twice the size of UTF-8 for English text. Anything that leaves the process should use a named encoding.

4The UTF-8 BOM in bytes from a file

Some UTF-8 files start with a byte order mark, the three bytes EF BB BF. Notepad on older Windows and many Excel exports write it. File.ReadAllBytes hands you those bytes as they are, and GetString doesn't skip them: the BOM becomes an invisible U+FEFF character at the start of the string. Readers that know about it, File.ReadAllText and StreamReader, detect it and drop it.

using System.Text;

// A UTF-8 file written with a byte order mark starts with EF BB BF
File.WriteAllText("bom.txt", "hello", new UTF8Encoding(encoderShouldEmitUTF8Identifier: true));
File.WriteAllText("plain.txt", "hello");   // default: UTF-8 without a BOM

byte[] bom = File.ReadAllBytes("bom.txt");
Console.WriteLine(Convert.ToHexString(bom));
Console.WriteLine(Convert.ToHexString(File.ReadAllBytes("plain.txt")));

// GetString keeps the BOM as an invisible U+FEFF character
string s = Encoding.UTF8.GetString(bom);
Console.WriteLine($"{s.Length} {s == "hello"} U+{(int)s[0]:X4}");

// Skip it yourself...
ReadOnlySpan<byte> preamble = Encoding.UTF8.Preamble;
ReadOnlySpan<byte> body = bom.AsSpan().StartsWith(preamble) ? bom.AsSpan(preamble.Length) : bom;
Console.WriteLine(Encoding.UTF8.GetString(body) == "hello");

// ...or let a reader detect it: File.ReadAllText and StreamReader strip it
Console.WriteLine(File.ReadAllText("bom.txt") == "hello");
using var reader = new StreamReader(new MemoryStream(bom));
Console.WriteLine(reader.ReadToEnd().Length);

// Encoding.UTF8.GetBytes never adds a BOM
Console.WriteLine(Encoding.UTF8.GetBytes("hello").Length);

The file with the BOM is EFBBBF68656C6C6F and the default one is 68656C6C6F. Decoding the first gives 6 False U+FEFF: the string looks like hello when printed but has six characters and isn't equal to it, which breaks comparisons, CSV headers and JSON parsers. Skipping Encoding.UTF8.Preamble by hand gives True, File.ReadAllText gives True, and the StreamReader reads 5 characters. GetBytes never writes a BOM (5 bytes for hello), but passing Encoding.UTF8 to File.WriteAllText or a StreamWriter does. Use new UTF8Encoding(false), or leave the encoding out, to write files without one.

5Invalid bytes and bytes that arrive in chunks

Not every byte array is valid UTF-8. By default GetString doesn't throw: it replaces each bad sequence with U+FFFD, the replacement character, and carries on. That is the right call for display, and the wrong one when bad bytes mean corrupt data. For that, build a UTF8Encoding with throwOnInvalidBytes: true. A second way to get replacement characters is decoding a stream chunk by chunk, because a multi-byte character can straddle two chunks. A Decoder holds on to the unfinished bytes between calls.

using System.Text;

// 0xFF never appears in UTF-8, and C3 starts a 2-byte char that never ends
byte[] bad = [0x48, 0x69, 0xFF, 0x21, 0xC3];

// Default: each bad sequence becomes U+FFFD, the replacement character
string lenient = Encoding.UTF8.GetString(bad);
Console.WriteLine(lenient);
Console.WriteLine(string.Join(" ", lenient.Select(c => ((int)c).ToString("X4"))));

// Strict: throw instead of guessing
var strict = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false, throwOnInvalidBytes: true);
try
{
    strict.GetString(bad);
}
catch (DecoderFallbackException e)
{
    Console.WriteLine($"{e.GetType().Name}: {e.Message}");
}

// Bytes that arrive in chunks can split a character in two
byte[] euro = Encoding.UTF8.GetBytes("€");   // E2 82 AC
byte[] part1 = [euro[0], euro[1]];
byte[] part2 = [euro[2]];

// Decoding each chunk on its own breaks it
Console.WriteLine(Encoding.UTF8.GetString(part1) + Encoding.UTF8.GetString(part2));

// A Decoder keeps the unfinished bytes between calls
Decoder decoder = Encoding.UTF8.GetDecoder();
var sb = new StringBuilder();
char[] buffer = new char[16];
foreach (byte[] chunk in new[] { part1, part2 })
{
    int n = decoder.GetChars(chunk, 0, chunk.Length, buffer, 0);
    Console.WriteLine($"chunk of {chunk.Length} -> {n} chars");
    sb.Append(buffer, 0, n);
}
Console.WriteLine(sb.ToString());

The lenient decode prints Hi�!�, which is 0048 0069 FFFD 0021 FFFD: one replacement for the stray FF and one for the unfinished C3. The strict encoding throws DecoderFallbackException: Unable to translate bytes [FF] at index 2 from specified code page to Unicode. Decoding the two halves of € separately prints ��, two replacements and no euro sign. The Decoder returns 0 chars for the first chunk, keeps its two bytes, and returns 1 char once the last byte arrives, so the result is €. You rarely need one by hand: StreamReader uses a Decoder internally, so reading text from a Stream through it handles the split for you.

6Which should you use?