UTF-8 Encoder

Encode text into UTF-8 byte values.

Text

Format

UTF-8 Bytes

Understanding UTF-8 Byte Encoding

UTF-8 is the dominant text encoding on the web. ASCII characters take a single byte, while accented letters, symbols, and emoji span two to four bytes. This tool encodes your text to its raw UTF-8 bytes and shows them as hexadecimal or decimal — useful for debugging encoding issues, building byte arrays, or inspecting how multi-byte characters are stored. Pairs with the UTF-8 Decoder. Runs entirely in your browser.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Producing the exact byte sequence for a string so you can compare it against what a parser or hash function received.
Working out how many bytes a field will occupy when the limit is in bytes and the content is not ASCII.
Building a test fixture that deliberately exercises one, two, three and four byte characters.
Checking whether two strings that look identical are actually the same bytes before blaming a comparison.
Preparing a hex byte sequence for a protocol that specifies its encoding explicitly.

Frequently Asked Questions

How many bytes does a character take?: One to four. ASCII stays at one byte, most Latin/Greek/Cyrillic take two, most CJK and the rest of the Basic Multilingual Plane take three, and emoji and rare scripts take four.
Why did UTF-8 win over UTF-16 and UTF-32?: Backward compatibility and self-synchronisation. ASCII files are already valid UTF-8, and because continuation bytes always start 10, a decoder that starts mid-stream can find the next character boundary — neither property holds for UTF-16.
What is an overlong encoding?: Encoding a character in more bytes than necessary, such as writing / as C0 AF instead of 2F. It is forbidden because it was a real security hole — path filters checking for the short form missed the long one and allowed directory traversal.
Why is my string length wrong?: Because the unit differs by language. JavaScript's .length counts UTF-16 code units and charges most emoji 2; Python 3 counts code points; a byte length counts UTF-8 bytes. For user-visible characters you need grapheme clusters, which is a fourth number.
Should I write a BOM?: No. UTF-8 has no byte order, so the mark is redundant, and it actively breaks shebang lines, CSV headers and PHP output. Some Windows tools still add it, which is why files occasionally begin with a stray .
Why are surrogate code points not encodable?: Because U+D800-U+DFFF exist only to let UTF-16 address higher planes, and have no meaning as characters. Encoding them produces CESU-8 rather than UTF-8, which is why a strict encoder rejects them outright.
What is normalisation and why does it matter before encoding?: The same visible text can be several code point sequences — `é` as one character or `e` plus a combining accent. They encode to different bytes, so comparison, hashing and deduplication all need a normalisation form chosen first.

Common errors and gotchas

Assuming a character is one byte. Accented letters take two, most CJK three and emoji four, which is where byte limits break.
Comparing strings that look the same but are normalised differently. Composed and decomposed forms encode to different bytes.
Writing a byte-order mark into UTF-8 output. It is permitted, almost never wanted, and it breaks naive parsers.
Trying to encode a lone surrogate. Those code points exist only inside UTF-16 and have no valid UTF-8 representation.
Producing an overlong encoding by padding a short character into more bytes. It decodes, but it is invalid and rejected as a security risk.