Unicode converter

The four counts, and why they disagree

A grapheme is what a person means by a character — the thing one press of backspace removes. A code point is what the Unicode standard assigns a number to. A UTF-16 code unit is what JavaScript reports from .length, because JavaScript strings are stored as UTF-16. A UTF-8 byte is what a database column, a network payload and a file size actually measure. For unaccented English all four are the same number, which is exactly why nothing breaks until the first emoji or the first name with an é in it.

😀 is one grapheme, one code point, two UTF-16 units and four UTF-8 bytes. So "😀".length is 2, and slicing that string at position 1 leaves one half of a surrogate pair, which is not a character at all; that is where the replacement diamond in a truncated post comes from. 👨‍👩‍👧 goes further: one grapheme, five code points, eight UTF-16 units and eighteen bytes, because it is a man, a woman and a girl joined by two zero-width joiners whose only job is to say "draw these as one". Paste it in and the table shows all five rows, two of them with nothing visible in the character column. Those are the joiners, and they are also why deleting a family emoji sometimes takes several presses.

Which count your limit should be using

It depends what the limit is protecting. A database column is measured in bytes, so a VARCHAR(20) in a UTF-8 table holds twenty bytes and not twenty characters. A display limit, the kind that says "no more than 40 characters", wants graphemes, because that is what a reader perceives and what a text box appears to hold. An API limit is whatever the API documented, which is worth reading rather than assuming, since the three answers can differ by a factor of four on the same string.

The byte count is where the most common Unicode bug in production lives. MySQL has an encoding named utf8 that stores at most three bytes per character, and every emoji needs four, so the column has to be utf8mb4, where the mb4 is literally maximum bytes 4. An emoji that vanishes between a form submission and the page it renders on is nearly always this, and the character is genuinely gone rather than hidden.

What this page does not tell you

The Block column is a range lookup rather than a full character-database query, so it says "Latin-1 Supplement" and not the formal name LATIN SMALL LETTER E WITH ACUTE. It is enough to orient you, and the official code charts are linked below when the name is what you need. The table also stops at 300 characters and says so when it truncates, which is far more than anyone needs to diagnose one string and keeps a pasted document from freezing the page. The four counts above it always cover the whole input, however long it is.

The grapheme count comes from Intl.Segmenter, which every current browser has. Where it is missing the number falls back to the code-point count rather than guessing, so on a very old browser the first two rows read the same. One case is worth naming because these counts are what settle it: two strings that look identical on screen and do not compare equal are almost always a normalisation difference, where é exists both as one code point and as a plain e followed by a combining acute. The table shows that immediately as one row against two, with the code-point count reading 1 against 2. The fix is a normalisation pass rather than anything on this page, and the text cleaner carries NFC and NFKC.