How to Use the UTF-8 Encoder Decoder, Step by Step
Reviewed by the OnlineFree.app team · Updated
Key points
- UTF-8 maps each Unicode code point to one to four bytes and is fully reversible, so it is a representation, not encryption.
- The UTF-8 Encoder Decoder runs entirely in your browser, so pasted text and hex bytes never leave your device.
- An emoji like 🌍 is four UTF-8 bytes, one code point, and two UTF-16 code units.
- Percent-encoding triples byte counts: 你好 becomes %E4%BD%A0%E5%A5%BD, an 18-character string.
- Valid UTF-8 is not always correct text — double-encoded mojibake such as ä½ å¥½ still passes validation.
What the UTF-8 Encoder Decoder does
The UTF-8 Encoder Decoder converts text to UTF-8 hex bytes, hex bytes back to text, or text to percent-encoding, and validates every byte it touches. It reports the exact offset and cause of each illegal sequence instead of quietly substituting a replacement character.
Encoding is not encryption. UTF-8 is a reversible way to represent Unicode code points as 1 to 4 bytes, so anyone with the bytes can recover the text. The tool is a debugging instrument for encoding mismatches, not a way to hide data.
We built it for the everyday failure mode: a database, HTTP header, or log file shows 乱码 (mojibake), and you need to know whether the bytes are malformed, truncated, or simply mislabelled. All conversion and checking runs in the browser, so nothing you paste is uploaded.
Step 1: choose a mode and paste your input
Three modes sit at the top of the page: text to UTF-8 hexadecimal bytes, UTF-8 hexadecimal bytes back to text, and text to percent-encoding. Use the first when you want to see what bytes a string produces, the second when you have a byte dump and want to know what it says, and the third when you are building a query string or form body.
Then paste into the input box. In hex mode the parser ignores spaces, line breaks, commas and 0x prefixes, so 0xE4 0xBD 0xA0, E4 BD A0 and E4BD,A0 all parse identically. There is no submit button: results refresh as soon as you stop typing.
The input field accepts up to about 200,000 characters. Past that, the tool tells you to split the payload rather than locking up the tab — a deliberate choice, since a silent freeze is worse than a blunt warning.
How do you read the byte grid and validation report?
Output appears as a monospaced hex grid with an offset ruler: rows begin at 0000, 0010, 0020 and so on, 16 bytes per row on a wide screen and 8 bytes per row on a phone. A copy button sits next to the result block.
Above the grid is a fixed summary line: a valid/invalid badge plus three counts — byte length, Unicode code points, and UTF-16 code units. Those numbers disagree more often than people expect. The string 你好 is 6 bytes, 2 code points and 2 UTF-16 code units; a single 🌍 is 4 bytes, 1 code point and 2 UTF-16 code units.
When the bytes are invalid, the report panel lists each offending byte with its offset, an error type, and a short explanation. Offsets are zero-based and follow the same ruler as the grid, so you can match a report entry to the highlighted byte. Remember that the report judges UTF-8 structure only — valid bytes are not proof the text is what you meant to send.
The illegal UTF-8 sequences the checker flags
An orphan continuation byte is a byte in the range 0x80–0xBF appearing where a start byte is expected. This usually means the front of a string was cut off mid-character, which is what happens when a fixed-length field or a chunked read slices through a multi-byte character.
A truncated sequence is the mirror case: the leading byte promises more bytes than the buffer supplies. E4 BD alone is incomplete, because E4 signals a three-byte character and only one continuation byte follows.
The checker also catches illegal start bytes (0xC0, 0xC1, and 0xF5–0xFF), overlong encodings such as C0 80 used to spell NUL in two bytes, surrogate code points written directly in UTF-8 (ED A0 through ED BF, i.e. U+D800–U+DFFF), and code points above U+10FFFF such as F4 90 80 80. These rules are defined in RFC 3629.
This strictness is the reason we did not rely on the browser alone. TextDecoder normally replaces malformed input with U+FFFD rather than throwing, which erases the byte position you need for debugging; the tool therefore runs its own byte-by-byte state machine alongside the native decoder.
Why byte counts matter more than character counts
Take 你好, which is U+4F60 U+597D: six UTF-8 bytes, E4 BD A0 E5 A5 BD, two code points, two UTF-16 code units. Latin text is one byte per ASCII character, CJK is three, and anything above U+FFFF is four — so a field sized in characters can overflow when the content changes language.
Percent-encoding multiplies the byte count. Every byte becomes %XX, which follows RFC 3986, so 你好 becomes %E4%BD%A0%E5%A5%BD — 18 characters instead of 6 — and 🌍 becomes the 12-character string %F0%9F%8C%8D. URL length limits bite long before storage limits do.
UTF-16 comparisons matter too. For CJK-heavy text, UTF-16 uses 2 bytes per character against UTF-8's 3, which is why some in-memory formats look smaller; for mostly-ASCII payloads UTF-8 wins easily. If a column, index prefix, or protocol field has a byte ceiling, check the actual byte count before you commit — and confirm the exact limit against your database version's documentation, since the tool cannot know your schema.
Limits, privacy, and what the tool cannot do
Nothing you paste is uploaded, logged, or stored. There is no account, no history, and no settings page, and the page keeps working offline once loaded. The same browser-only pattern runs across the rest of our free online tools, including the AI Visibility Tracker.
The most important limitation is subtle: double-encoded mojibake can be perfectly valid UTF-8. If UTF-8 bytes were once decoded as Latin-1 and then re-encoded, 你好 may arrive as the string ä½ å¥½ — structurally valid, semantically wrong. The validator will pass it, and you will need to reverse the wrong step manually.
Two smaller caveats: the input cap is around 200,000 characters, so very large log files need chunking, and the report describes bytes, not intentions. It cannot tell you which system in your pipeline mangled the data. For anything critical — migrations, signed payloads, protocol buffers — verify the final bytes with your own runtime, not only with a web page.
Frequently asked questions
Is the UTF-8 Encoder Decoder safe for confidential data?
Yes. All conversion and validation happens inside your browser tab using native TextEncoder/TextDecoder plus a local UTF-8 state machine. Nothing is uploaded, logged, or stored, there is no account, and the page keeps working offline once loaded. The usual caveats still apply: avoid pasting secrets on a shared machine or with untrusted browser extensions installed.
Why does my browser show U+FFFD instead of pointing to the bad byte?
Because TextDecoder normally replaces malformed input with the replacement character U+FFFD instead of throwing, which destroys the byte position you need. This tool runs a strict state machine, equivalent to decoding with fatal: true, so it reports the offset and error type of the first illegal sequence and you can inspect the original bytes.
How many bytes do 你好 take in UTF-8 and in percent-encoding?
你好 is two code points and six UTF-8 bytes: E4 BD A0 E5 A5 BD. Percent-encoding rewrites each byte as %XX, so the same string becomes %E4%BD%A0%E5%A5%BD, an 18-character string — three times longer. A single emoji such as 🌍 is four bytes (F0 9F 8C 8D) and 12 characters when percent-encoded.
Does the tool handle emoji and other characters outside the BMP?
Yes. Code points above U+FFFF are encoded as four UTF-8 bytes and counted as one code point but two UTF-16 code units, because they need a surrogate pair. The validator also flags surrogate code points written directly in UTF-8 (ED A0 through ED BF), which are illegal under RFC 3629 even though some older encoders produced them.
What is the input limit, and can it process large log files?
The input field accepts up to roughly 200,000 characters; beyond that the tool warns you instead of freezing the tab. For larger dumps, split the payload at a safe character boundary and check each chunk, or test the first few hundred bytes surrounding the point where your reader or parser first broke.