What every character is really made of
How text is stored as numbers, why the length you see is not always the length a computer counts, and how to use the Character Inspector to find the hidden pieces inside any string.
Characters are numbers underneath
Every letter, digit and symbol on a screen has a number behind it. That number is its code point. The letter A is 65. A space is 32. The standard that assigns these numbers is called Unicode, and it covers more than 150,000 characters from every writing system in active use, plus thousands of emoji, math symbols and historic scripts.
Code points are written in a short form that starts with U+ and then gives the number in hexadecimal. A is U+0041. A Hindi vowel might be U+0905. A fire emoji is U+1F525. These are the real names of the characters, and they never change once assigned.
Most of the time none of this matters. You type, it appears, life goes on. But the moment something breaks - a name that will not sort, a search that finds nothing, a field that rejects valid input - the code points are the place to look. The Character Inspector shows them.
Paste it in and read what comes out
The page has a text area on the left labelled Text. Paste anything into it. Below the settings bar there is a hint that says paste anything, including emoji. The output appears on the right under the heading Every character.
Each character gets a row in a table. You see the character itself, its code point in U+ form, its official Unicode name, its general category and how many bytes it takes in UTF-8. If the Show the encoded bytes and Show escape forms checkboxes are ticked, you also see the raw byte values and the escape sequences you would use in code or HTML.
A status line at the bottom counts the characters. This count may surprise you, and that surprise is often the whole reason you are here.
The settings that change the output
The Show dropdown at the top offers two views. A table of every character is the default, listing one row per code point. A summary by script groups the characters by writing system instead, which is handy when you are checking whether a string mixes scripts - a common sign of a spoofed domain name.
Include plain ASCII characters is ticked by default. Untick it when you only care about the unusual characters and want to skip the ordinary letters and digits.
Show the encoded bytes adds a column with the raw UTF-8 bytes for each character. Show escape forms adds a column with the JavaScript escape, the HTML numeric entity and the HTML named entity where one exists. Both are ticked by default. Turn them off if you want a cleaner table.
Why the count is not what you expect
A flag emoji is not one character. It is two code points, each representing a letter from a country code, joined by Unicode into a single visible flag. A family emoji can be seven code points linked by invisible joiners. An accented letter might be one code point, or it might be two - the base letter followed by a separate combining accent mark.
This is why a field that allows twenty characters sometimes rejects a fifteen-letter name. The field is counting code points or bytes, not the shapes you can see. It is also why two strings that look exactly the same can fail an equality check. One might spell the accented e as a single code point, while the other spells it as e plus a combining acute accent. They look the same on screen, but they are different sequences of numbers.
The table makes this visible. If an accented letter shows as two rows, the text uses the decomposed form. If it shows as one row, it uses the composed form. Knowing which you have is the first step to fixing a mismatch.
A worked example with mixed scripts and emoji
Suppose a user registers with the name Rene followed by a party popper emoji. You paste it in. The table shows five rows for the letters R, e, n, e, and then two or three rows for the emoji depending on which party popper variant it is. The total might be six, seven or eight code points for what looks like five characters.
Now try the name with an accent: Rene with the e at the end carrying an acute accent. If the accent is composed, you still see five letter rows. If it is decomposed, the accented e splits into two rows - the plain e and a combining acute accent. The byte count column shows the combining mark is two bytes on its own.
This is the kind of test that saves an afternoon of debugging. The data is right there in the table, no guesswork needed.
Bytes, storage and where fields overflow
UTF-8 is the most common way to store text on the web. It uses a variable number of bytes per character. Plain English letters take one byte each. Most accented Latin letters and Greek, Cyrillic and Arabic characters take two bytes. Chinese, Japanese and Korean characters take three. Emoji take four.
A database column defined as VARCHAR(20) might mean twenty bytes, twenty code points or twenty characters depending on the database. If it means twenty bytes, it holds twenty English letters but only five emoji. The byte count column in the table answers the question directly.
This also matters for APIs with size limits, for SMS messages that switch from seven-bit encoding to Unicode at the first non-ASCII character, and for any protocol that counts octets rather than visible symbols. When a form rejects valid input, the byte column usually explains why in a glance.
Escape forms and when you need them
Sometimes you cannot put a character directly into source code or a configuration file. A null byte would terminate a C string. A less-than sign would start an HTML tag. A backslash would begin an escape sequence in most programming languages.
The escape forms column gives you three ready-made alternatives for each character. The JavaScript escape is the form you would use inside a string literal. The HTML numeric entity works in any HTML document. The HTML named entity, where one exists, is the readable version - for example, the ampersand has a named entity but an obscure math symbol does not.
You can copy any of these directly from the output using the Copy button. They are not translations or approximations; they are exact representations of the same code point in a format that is safe for the context you need.
Spotting problems before they reach production
- Two words that look identical but do not match in a search. Paste both. If one uses a Latin o and the other uses a Cyrillic o, the code points will differ even though the shapes are the same.
- A username that passes validation on one system and fails on another. Check the byte count. The system that rejects it probably has a byte limit, not a character limit.
- An email address with an invisible character in it. The table shows every code point, including zero-width joiners, soft hyphens and other characters that do not render.
- A CSV file where one column sorts wrong. If the data mixes composed and decomposed forms of the same accented letter, they will sort as different characters.
- A web page where an HTML entity renders as the literal text instead of the symbol. The escape forms column shows the correct entity to use.
Nothing leaves your machine
The entire inspection happens inside your browser. The text you paste is not sent to any server, not stored anywhere, and not visible to anyone but you. This matters because the strings that bring people to a tool like this are often the ones that contain personal names, customer data, or content from systems they are debugging.
You can confirm this by disconnecting from the internet and using the page. It works exactly the same way, because there is no network request to make. Closing the tab is all the cleanup there is. For sensitive debugging sessions where the data belongs to a client or a regulated system, that guarantee matters more than convenience.