Unicode Character Inspector

Paste anything and see it one code point at a time: the U+ value, the exact UTF-8 bytes, the UTF-16 units, the general category, the East Asian width and whether it is one of the characters that renders as nothing at all.

Code point, code unit, byte, grapheme

A code point is a number in the Unicode catalogue, written U+4E00. A code unit is a fixed-size piece of an encoding: UTF-16 uses one unit for most characters and two for anything above U+FFFF, while UTF-8 uses one byte for ASCII, two for most Latin accents and Greek, three for the CJK range, and four for the supplementary planes. A grapheme is what a reader calls one character, which may be several code points.

Almost every confusing text bug is a mismatch between two of those four. A limit expressed in one unit and enforced against another; a substring operation that cuts between the two halves of a surrogate pair and produces a broken box; a length check that passes and a database insert that fails. This page shows all four at once so you can see which pair disagrees.

One Chinese character is three bytes

This single fact explains a family of problems. A VARCHAR column sized in bytes holds a third as much Chinese as its number suggests. A QR code has a byte budget, not a character budget, so a Chinese payload fills it three times faster and needs a larger symbol. Filename length limits, HTTP header limits, SMS segment sizes and JSON payload caps are all measured in bytes.

The byte column here is the real UTF-8 encoding, not an estimate, so you can check a specific string against a specific budget. If you need to know why a field accepted a name in English and rejected the same person's name in Chinese, this is where you look.

The characters that render as nothing

Zero-width spaces, zero-width joiners, soft hyphens, byte-order marks, word joiners, directional marks and non-breaking spaces are all real characters that occupy length, participate in comparisons, and are completely invisible. They arrive by copying from web pages, PDFs, spreadsheets and chat apps, and they are the usual answer to "these two strings are identical but the comparison fails".

We print them in brackets with their code point, so the table shows you where they are rather than just telling you how many there are. Position matters: a zero-width space in the middle of a search term is a different problem from a byte-order mark at the start of a file, and only one of them is fixed by trimming.

Normalisation, and the one that quietly changes meaning

Normalise to NFC to compare text reliably: it composes accented letters into their single-code-point form, which is what most systems produce and expect. NFD does the reverse and is worth looking at when a filename from a Mac will not match. Both are lossless round trips.

NFKC is the one to be careful with. It folds compatibility characters — full-width Latin letters become ASCII, circled numbers become digits, ligatures are split — which is exactly what you want when normalising user input for search, and exactly what you do not want when the distinction carries meaning. Applying NFKC to Japanese text collapses half-width katakana; applying it to a document with full-width Latin in a Chinese context changes how the line lays out. Compare the two counts on this page before you decide.

East Asian width, and why fixed layout breaks

A CJK character occupies two columns in a monospaced context; a full-width Latin letter does too. That is why a terminal table aligned with spaces falls apart when a Chinese name appears in it, why a line-length limit counted in characters under-estimates Chinese text by roughly half, and why fixed-width text art rarely survives translation.

The width column reports the Unicode East Asian Width property: W for wide, F for full-width, H for half-width, Na for narrow, and A for the ambiguous class whose width depends on the surrounding context. Everything on this page runs in your browser, which matters because the strings people inspect are usually the ones already causing an incident: API keys, customer records, log lines and filenames.