About the Hex to UTF-8
UTF-8 spends one byte on ASCII, two on most European letters, three on the bulk of the world scripts and four on emoji and rarer symbols. That variable width is what makes a hex dump of UTF-8 confusing: the byte count and the character count are different numbers, and a character can straddle the line break in your dump. This decoder reassembles the sequences properly and shows the text.
Input is forgiving about layout. Spaces, colons, commas, semicolons, hyphens, underscores, dots, pipes and line breaks are stripped, and 0x, \x, % and &#x prefixes are removed, so bytes copied from a network capture, a percent encoded URL or a debugger view all work as they are. An odd number of digits is reported with the exact count, since the final byte would be incomplete.
Two switches matter. Strict mode uses a fatal decoder that refuses the whole input if any sequence is malformed, which is the right setting when you are checking whether a file really is valid UTF-8. With it off, broken sequences become replacement characters and the status line counts them, which is more useful when you are trying to read most of a damaged payload. The byte order mark option removes a leading EF BB BF, the invisible marker that Windows editors like to add and that otherwise shows up as a stray character at the start of the first field.
For the encoding direction and for other byte views, UTF-8 Converter and Hex Decode cover the neighbouring cases.
How to use
- Paste the hex bytes in any layout: spaced pairs, colons, a solid run or 0x values.
- Leave Remove a leading byte order mark ticked unless you need to see the marker.
- Turn on Fail on invalid UTF-8 when you are validating rather than reading.
- Copy the decoded text or download it.
Common questions
- Why does my accented letter take two bytes?
- UTF-8 encodes anything above code point 127 in two or more bytes, so é is C3 A9 rather than a single value.
- What is the byte order mark doing at the start?
- Some Windows editors write EF BB BF to flag the file as UTF-8. It is invisible in text but breaks header matching in CSV parsers.
- Strict mode fails but I can read the output without it. Which is right?
- Both. Strict mode proves the bytes are not valid UTF-8 anywhere, while the relaxed decoder shows you the parts that survived.
- Can I paste percent encoded bytes such as %E2%82%AC?
- Yes. The percent signs are treated as separators, so the sequence decodes to the euro sign.