Skip to content
ToolBoxGeniehome

Unicode Character Inspector

Text Tools · Added

When a name will not match a database row, a paste is rejected, or two apparently identical strings compare unequal, the cause is almost always a character you cannot see. This shows you every character in your text: its code point, its bytes in UTF-8 and UTF-16, how to escape it, and whether it draws anything at all.

Every character is broken down as you type. Nothing is uploaded.

Try:

How to use the unicode character inspector

  1. 1Paste the text that is behaving oddly into the box.
  2. 2Read the four counts at the top — they disagree, and all four are correct.
  3. 3Scan the table for rows shaded red: those characters occupy space without drawing anything.
  4. 4Copy the escape sequence for any character you need to write into code.

Examples

A curly apostrophe

Input
It’s fine
Result
U+2019 RIGHT SINGLE QUOTATION MARK, category Punctuation, three UTF-8 bytes

Pasted from a word processor, this will not match a string typed with a straight apostrophe.

An emoji with a combining sequence

Input
A family emoji
Result
5 code points · 8 UTF-16 units · 18 UTF-8 bytes · 1 grapheme

A field limited to 10 characters accepts or rejects this depending on which of the four it counts.

About the unicode character inspector

The characters that cause the most trouble

Three offenders account for most of the cases where text misbehaves. The non-breaking space, U+00A0, arrives with anything copied out of a web page or a PDF and is indistinguishable from a normal space on screen. The zero-width space, U+200B, gets inserted by editors as a line-break hint and survives into your data. And the right single quotation mark, U+2019, is what a word processor produces when you type an apostrophe.

None of these is a bug in the software that produced them. They are correct typography that becomes a data problem the moment somebody compares two strings byte for byte.

Why a length limit is a question, not an answer

A field that accepts 100 characters has to decide what a character is, and different systems answer differently. A VARCHAR(100) in one database counts bytes, in another counts characters. A JavaScript check on string length counts UTF-16 units. An SMS gateway counts something else again.

The practical consequence is that a form which happily accepts 100 characters of English may reject 60 characters of Japanese, or truncate an emoji halfway through and produce a broken surrogate pair. If you are enforcing a limit, decide which unit you mean and count that one deliberately.

Frequently asked questions

Why do the four counts disagree?
Because they measure different things. A grapheme is what a reader would call one character. A code point is one Unicode value. A UTF-16 unit is what JavaScript's string index steps through, and anything above U+FFFF takes two of them. A UTF-8 byte is what travels over the network and what most databases store. An accented letter written as a base plus a combining mark is one grapheme, two code points, two UTF-16 units and three UTF-8 bytes — every one of those figures is right.
Why does it show the block rather than the character's name?
The official names live in UnicodeData.txt, about 1.9 MB covering roughly 150,000 code points. Downloading that to label a handful of characters would weigh more than the whole rest of this site. The block comes from a compact range table and the category from the browser's own regular expression engine, so both are true statements rather than guesses.
What are the rows shaded red?
Characters that take up no visible space: control codes, format characters such as the zero-width joiner, and every space that is not the ordinary U+0020. Those are the ones worth hunting for, because they look like nothing on screen while still counting towards a length limit and still defeating an equality test.
Does the text I paste go anywhere?
No. Every count and every table row is worked out by JavaScript running on your own machine. Nothing leaves the page, and closing the tab is the end of it.