UTF-8 Byte Inspector

What this tool does

UTF-8 Byte Inspector breaks text down character by character, showing each code point, its UTF-8 bytes in hex and bits, its UTF-16 code units and its Unicode category. In hex mode it validates raw bytes against RFC 3629 and pinpoints truncated, overlong and otherwise invalid sequences.

Text that looks perfectly normal can hide surprises: a zero-width space that breaks a password check, a byte order mark that corrupts a CSV header, a curly quote pasted from a word processor, or an emoji that a database column truncates halfway. The usual length counters do not help, because “length” means different things in different places. A database may count UTF-8 bytes, JavaScript counts UTF-16 code units, and a person counts visible characters.

This inspector shows all of those at once. For each character you see its byte offset, its code point in U+ notation with a name for common invisible characters, its UTF-8 bytes in hex and in binary with the marker bits highlighted (0 for ASCII, 110, 1110 or 11110 for lead bytes, 10 for continuation bytes), its UTF-16 units including surrogate pairs, and its Unicode general category. Totals cover bytes, code points, grapheme clusters and UTF-16 units. Switch to hex mode to check raw bytes from a file or packet: the strict RFC 3629 validator reports stray continuation bytes, truncated sequences, overlong encodings, encoded surrogates and values above U+10FFFF, with their offsets. Nothing leaves your browser.

How to use UTF-8 Byte Inspector

1. Choose Text or Hex bytes as the Input type in the Options panel.
2. Paste the text, or the hex bytes, into the input box, or click Sample.
3. Read the totals: UTF-8 bytes, code points, graphemes and UTF-16 code units.
4. Check the warnings for byte order marks, invisible characters and invalid sequences.
5. Scan the Character breakdown table, switching on “Show only non-ASCII characters” to focus on multi-byte ones.
6. Click Download CSV to save the full breakdown.

Tips for better results

• An emoji with a skin tone, such as 👋🏽, is two code points and one grapheme, and takes 8 UTF-8 bytes.
• MySQL’s legacy utf8 type stores at most 3 bytes per character; any row here with 4 bytes needs utf8mb4.
• The sequence EF BB BF at offset 0 is a byte order mark; many parsers treat it as part of the first field name.
• C3 followed by a byte that is not 80-BF usually means Latin-1 text was mixed into UTF-8 data.

Common use cases

• Finding the invisible character that makes two identical-looking strings compare unequal.
• Checking whether a username or tweet fits a byte-based limit.
• Debugging mojibake such as “é” by looking at the underlying bytes.
• Teaching how UTF-8 variable-length encoding works, bit by bit.

Common mistakes to avoid

• Using JavaScript’s string length as a byte count; it counts UTF-16 units, so “é” is 1 but needs 2 bytes.
• Treating code points as visible characters. Accents can be separate combining marks, and flags are pairs of regional indicators.
• Pasting bytes from a Windows-1252 file into the hex mode and expecting valid UTF-8; such bytes above 7F are almost always reported as invalid.