Character Inspector – See Any Character’s Unicode Details
This character inspector shows any character or string’s Unicode code point, UTF-8 and UTF-16 byte encoding, HTML numeric reference, category, and block — invisible characters, emoji, accented letters, or ordinary text.
Inspect Any Character’s Unicode Encoding
Enter a single character or a full sentence. Each Unicode code point is broken down on its own row, so you can see exactly how your text is encoded at the byte level. Note that a single displayed emoji or accented letter can be made up of more than one code point, so it may span multiple rows.
| Pos | Char | Code Point | UTF-8 | UTF-16 | HTML Numeric Ref | Category | Block |
|---|---|---|---|---|---|---|---|
| Enter text above and select Inspect Text to see the breakdown. | |||||||
Quick Codepoint to Character Converter
Type a Unicode code point, such as 1F600 or U+1F600, to see the actual character and its encoded forms.
Unicode Normalization Checker
Compare the same text rendered in NFC, NFD, NFKC, and NFKD normalization forms. Useful for finding why two strings that look the same fail an equality check.
Calculated with the browser’s built-in String.normalize method, no external library required.
Where This Character Inspector Helps
String Comparison Bugs
Find the exact code point causing two strings that look identical to fail an equality check in your code.
Database and API Mismatches
Diagnose encoding mismatches between what a client sends and what a database or API expects to store.
Font and Glyph Issues
Identify whether a rendering problem is a missing font glyph or an actual encoding error in the underlying text.
Payload Validation
Check the raw encoding of text before sending it in an API payload, especially for multilingual or symbol-heavy content.
How This Character Inspector Reads Your Text
Every character you type or paste is stored internally as one or more numeric code points, values defined by the Unicode Standard that identify text content independently of the font used to render it. The same code point can look different across fonts, since a code point identifies what the character is, not how it must be drawn. This tool reads each code point in your input and converts it into the formats developers actually work with: raw UTF-8 byte sequences, UTF-16 code units (including surrogate pairs for characters outside the Basic Multilingual Plane), the decimal HTML numeric reference, and the general Unicode category assigned to that code point.
Character encoding checks matter most when text moves between systems that assume different formats. A string typed in one application, saved to a database configured for a different character set, then returned through an API, can pick up subtle encoding errors along the way. Two strings can look identical on screen yet fail a strict equality check because one contains a precomposed accented letter while the other stores the base letter plus a separate combining mark, a difference that only becomes visible once you inspect the underlying code points. Note that what looks like a single “character” on screen — an emoji sequence joined with ZWJ, a flag made of two regional-indicator code points, or a letter plus a combining accent — can be made up of several code points, so this tool’s row-by-row breakdown is by code point, not by displayed character.
This is also why Unicode normalization matters for multilingual text handling. The same character can be represented by more than one valid sequence of code points, and normalization forms such as NFC, NFD, NFKC, and NFKD define consistent rules for converting those variants into a single canonical or compatibility form. Normalization resolves this kind of code-point-level equivalence — it doesn’t guarantee that two strings which merely look alike will become identical, only that equivalent representations of the same underlying text will match. The Normalization Checker above lets you see how a given piece of text is represented under each form, along with the resulting character and byte length, so you can decide which form your application should standardize on before storing or comparing user input.
Unlike a security scanner, this tool does not flag characters as risky or hidden. It simply reports what a code point is and how it is encoded, whether that character is a plain ASCII letter, an emoji built from a multi-byte sequence, a diacritic mark, or an invisible formatting character. The block name shown for each code point is a named, contiguous range of code points used to organize the Unicode code charts — it’s a useful pointer to where a character comes from, but it isn’t a guarantee about how that character behaves in any given application. If you specifically need to find hidden or disguised characters in a block of text for security review, the Invisible Character Detector is built for that job.
Coverage note: the block and category lookups in this tool cover a large but not fully exhaustive slice of the Unicode Standard, which is a large and actively growing specification (Unicode 17.0 is the current published version at time of writing). A code point in a very new or lesser-used block may be labeled with a generic fallback rather than its exact block name — see the FAQ below.
Character Inspector FAQ
What is the difference between UTF-8 and UTF-16?
UTF-8 encodes each Unicode scalar value using one to four bytes and is backward compatible with ASCII, which makes it the standard for web pages and APIs. UTF-16 encodes characters using one or two 16-bit code units and is common inside programming languages such as JavaScript and Java. The same character can therefore have a different byte-level representation depending on which encoding a system uses.
Why does my string comparison fail even though the text looks identical?
The two strings likely use different underlying code points to produce the same visible result, commonly because one uses a precomposed character and the other uses a base character combined with a separate accent mark. Running both strings through the same normalization form before comparing them usually resolves this.
What is Unicode normalization and when do I need it?
Normalization converts equivalent code-point sequences into a consistent representation, so that different ways of encoding the same underlying text also match at the code point level. It matters whenever you store, search, or compare user-submitted text, especially multilingual content with accented or combining characters.
Why do two characters that look the same have different code points?
Unicode contains multiple code points that render as visually similar or identical glyphs, drawn from different scripts, symbol blocks, or compatibility ranges. Two characters can appear indistinguishable in a given font while belonging to entirely separate parts of the Unicode Standard.
Does this inspector work for emoji and multi-byte characters?
Yes. Emoji and other characters outside the Basic Multilingual Plane are handled correctly, including the surrogate pair breakdown for UTF-16 and the full multi-byte sequence for UTF-8. Keep in mind a single displayed emoji can be built from several code points (for example, a ZWJ sequence or a flag made of two regional-indicator letters), so it may appear as multiple rows.
What is a Unicode block and why does it matter?
A Unicode block is a named, contiguous range of code points used to organize the Unicode code charts, such as Basic Latin or CJK Unified Ideographs. Unicode itself notes that block membership isn’t a reliable guide to a character’s properties or intended use — it’s mainly a way to locate a code point within the standard. It’s still a useful pointer when inspecting unexpected characters in a dataset, but pair it with the category and script properties for anything that matters.
Why does a character show a generic or fallback block/category label?
This tool checks a large set of common Unicode blocks and category properties, but the full Unicode Standard is much bigger and grows with every new version. A code point from a newer, rarer, or highly specialized block may not be in this tool’s lookup table and will show as an uncatalogued range or unassigned category here even though it is a valid, assigned Unicode character. Treat that label as “not in this tool’s lookup table” rather than “not part of Unicode.”