UTF-8 Encoder Online — Text to UTF-8 Bytes

Unicode assigns every character a code point, such as U+0041 for "A" or U+1F600 for "😀". UTF-8 and UTF-16 are two different ways of storing those code points as bytes. UTF-8 uses 1 to 4 bytes per character: "A" becomes 41, "€" becomes E2 82 AC, and "😀" becomes F0 9F 98 80. UTF-16 uses 2 or 4 bytes: "A" is 00 41 and "😀" is stored as the surrogate pair D8 3D DE 00. UTF-8 is backward compatible with ASCII and is used by over 98% of websites, which is why this encoder targets UTF-8.

A code point is the character's number in the Unicode standard, written like U+00E9 for "é". A byte is 8 bits of physical storage. One code point becomes 1 to 4 bytes in UTF-8: "é" (U+00E9) needs 2 bytes (C3 A9), and "€" (U+20AC) needs 3 bytes (E2 82 AC). Confusing the two causes real bugs: a database column limited to 100 characters holds 100 ASCII letters but only 25 four-byte emoji, because the limit is counted in bytes, not characters.

The code point range decides the byte count. U+0000 to U+007F uses 1 byte with the pattern 0xxxxxxx (plain ASCII). U+0080 to U+07FF uses 2 bytes: 110xxxxx 10xxxxxx. U+0800 to U+FFFF uses 3 bytes: 1110xxxx 10xxxxxx 10xxxxxx. U+10000 to U+10FFFF uses 4 bytes: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx. The leading bits of the first byte signal how many continuation bytes (each starting with 10) follow, which makes UTF-8 self-synchronizing: a corrupted byte damages only one character, not the rest of the stream.

A byte order mark is the invisible character U+FEFF. In UTF-16 it signals byte order (FF FE versus FE FF), but UTF-8 has no byte-order ambiguity, so a BOM is unnecessary and often harmful: the 3 bytes EF BB BF prepended to a UTF-8 file can break JSON parsers, PHP scripts ("headers already sent" errors), and CSV imports. This encoder never adds a BOM to its output.

JavaScript strings are stored as UTF-16, so any character above U+FFFF, like "😀" (U+1F600), is kept as two 16-bit surrogate units: D8 3D DE 00. UTF-8 has no surrogates; it encodes the code point directly in 4 bytes: F0 9F 98 80. A lone, unpaired surrogate is invalid in UTF-8, so encoders replace it with the replacement character U+FFFD (EF BF BD). This tool follows the same rule, matching the browser's built-in TextEncoder exactly.

That is the classic double-decoding bug: the 2 UTF-8 bytes of "é" (C3 A9) were read as if they were Latin-1 or Windows-1252, where C3 means "Ã" and A9 means "©". The fix is to decode those bytes as UTF-8. Use the per-character table above to inspect the real byte values of your text, or paste the raw bytes into our UTF-8 decoder to recover the original characters.

Take each UTF-8 byte and write it as %XX: "é" becomes %C3%A9 and "😀" becomes %F0%9F%98%80. That is exactly what JavaScript's encodeURIComponent does. Select the "Percent-encoded" output format above and the tool produces URL-ready text in one click, with uppercase hex digits just like the browser.

No. The encoding runs 100% in your browser using JavaScript; your text is never uploaded, logged, or stored anywhere. You can disconnect from the internet after the page loads and the encoder keeps working, because there is no server involved at all.