Text on a screen is a convenient illusion. What actually exists underneath is a sequence of numbers, each one a Unicode code point, and what gets stored in a file or sent over a network is a further encoding of those numbers into bytes. Most of the time that machinery is invisible and it should stay that way, but the moment a character renders as a mysterious box, an unexpected question mark, or behaves oddly in a script, seeing the actual code point and bytes involved is the fastest way to understand what is happening.
Every inspection happens locally in your browser using standard JavaScript string and encoding APIs. Nothing you paste is uploaded to a server, so this unicode character viewer is exactly as safe to use on a private password fragment or a client's proprietary text as it is on a public tweet.
What this unicode character viewer shows for each character
Every distinct character in your input gets its own row. The tool reads the text using Unicode aware iteration, so a character that spans more than one UTF-16 code unit, such as most emoji, is treated and reported as the single character it visually represents rather than being split into two confusing halves.
- The character itself, rendered at a larger size so unusual glyphs are easy to see.
- Its code point, written in the standard U+XXXX hexadecimal notation.
- Its decimal code point value, useful for programming contexts that expect a plain number.
- Its Unicode general category, such as uppercase letter, decimal digit or currency symbol, where the browser can determine it.
- Its UTF-8 byte representation, shown as hexadecimal byte pairs.
- The number of bytes the character occupies once encoded as UTF-8.
Why the same character can take a different number of bytes
UTF-8 is a variable width encoding, meaning different code points take a different number of bytes to store. A plain ASCII character such as the letter A takes exactly one byte, because UTF-8 was deliberately designed to be identical to ASCII for that first block of characters. An accented letter like e with an acute accent typically takes two bytes. Characters from scripts such as Chinese, Japanese, Korean, Thai or many currency symbols usually take three bytes. Many emoji, along with characters outside the earliest blocks of Unicode, take four bytes.
This matters in practice whenever something measures length in bytes rather than in visible characters, for example a database column defined with a byte limit, or an API with a payload size cap. Used as a UTF-8 byte viewer, this tool shows exactly how many bytes each character adds, and a string that looks short on screen can be considerably larger once encoded, particularly if it contains emoji or non Latin script.
Reading a Unicode general category
The general category is a short, standardised classification every assigned code point belongs to, defined by the Unicode Standard itself rather than by any particular programming language. Letters are split into uppercase, lowercase, titlecase, modifier and other letters. Numbers are split into decimal digits, letter numbers and other numeric forms. Punctuation, symbols, marks, separators and control characters each have their own set of subcategories.
Knowing the category answers practical questions a code point lookup on its own cannot, such as whether a character is expected to have an uppercase and lowercase form, whether it counts as whitespace, or whether it is a combining mark that attaches to the character before it rather than standing on its own. Used as a unicode category checker, this is the section of the report worth reading first when a character behaves unexpectedly.
Common uses for a code point lookup
Developers reach for this most often while debugging encoding problems, such as mojibake, the garbled text that appears when a file is read using the wrong character encoding. Used as a character encoding inspector, seeing the exact code point of a broken character usually reveals immediately whether the underlying text was correct all along and only the display was wrong, or whether the data itself was corrupted during a previous conversion.
Writers and researchers use it to identify a character copied from an unfamiliar source, confirm whether two visually identical characters are actually the same code point, which matters for search and comparison, or find the exact code point needed to enter a rare character using an operating system's Unicode input method.
Grapheme clusters, not code units, are what get segmented here
The tool uses the Intl.Segmenter API, where the browser supports it, to split the input into individual grapheme clusters, which is what lets a flag emoji or a family emoji built from several combined code points display and count as one character rather than several broken fragments. Each character's code point is read with the codePointAt method, and its UTF-8 bytes are produced with the TextEncoder API, the same encoder browsers use internally when sending text over the network.
General category detection uses a Unicode aware regular expression property escape, which is a native JavaScript feature that tests a character against the categories defined in the Unicode Standard without needing an external character database bundled into the page.
How to inspect a character's code point and bytes
- 1
Paste a character or block of text
Enter a single character, an emoji, or a longer piece of text you want to inspect.
- 2
Run the inspection
Press inspect to break the text down character by character.
- 3
Read the code point
Check the U+XXXX value and decimal code point for each character in the result table.
- 4
Check the category and bytes
Review the general category and the UTF-8 byte representation for anything unexpected.
- 5
Copy or download the report
Copy the full breakdown to your clipboard or download it as a plain text file.
Related tools worth bookmarking
Sources and further reading
- MDN: String.prototype.codePointAtThe browser method this unicode character viewer uses to read each character's numeric code point.developer.mozilla.org
- Unicode UAX #44: Character DatabaseThe specification defining the general category property this tool reports for each character.unicode.org
- WHATWG Encoding StandardThe specification behind the TextEncoder API used to produce the UTF-8 byte representation shown for each character.encoding.spec.whatwg.org
Frequently asked questions
Common questions about the unicode character viewer.
U+ is the standard Unicode notation prefix, always followed by the code point written in hexadecimal, for example U+0041 for the letter A. This unicode character viewer shows every character in exactly this format alongside its plain decimal equivalent, since different tools and specifications sometimes expect one or the other.
Many emoji, particularly ones with a skin tone modifier, a flag, or a family grouping, are built from a sequence of several separate code points joined together and rendered by the operating system as one visual glyph. This unicode character viewer displays the sequence so you can see every code point that contributes to the character you see on screen.
UTF-8 is a variable width encoding. Basic ASCII characters take one byte, most accented Latin letters take two, most characters from Chinese, Japanese, Korean and Thai scripts take three, and most emoji take four bytes. The number of bytes depends entirely on where the code point falls within the overall Unicode range.
For the vast majority of assigned code points, yes, using a native JavaScript regular expression feature built directly on the Unicode Standard's own category definitions. A very small number of unassigned or extremely new code points may not yet be recognised by an older browser's built in Unicode data.
No. Splitting into grapheme clusters uses Intl.Segmenter, reading each code point uses codePointAt, and the byte view comes from the browser's own TextEncoder producing UTF-8 bytes in memory, the same encoder used internally when a page sends text elsewhere, except here its output is only displayed rather than transmitted. None of those calls constructs a network request, so a private password fragment or a client's proprietary text is read only by the encoding calls running in your own tab.
Yes. Paste any length of text and every distinct character is broken out into its own row with its full code point, category and byte breakdown, so you can scan an entire sentence or paragraph for anything unexpected in a single pass.