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 entity, 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 character is broken down on its own row, so you can see exactly how your text is encoded at the byte level.
| Pos | Char | Code Point | UTF-8 | UTF-16 | HTML Entity | 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 visually identical strings 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 a numeric code point, a value defined by the Unicode Standard that uniquely identifies that character regardless of language, script, or font. 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 entity, and the general Unicode category assigned to that character.
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.
This is also why Unicode normalization matters for multilingual text handling. The same visual character can be represented in more than one valid sequence of code points, and normalization forms such as NFC, NFD, NFKC, and NFKD define consistent rules for collapsing those variants into a single canonical or compatibility form. 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 character 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. 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.
Character Inspector FAQ
What is the difference between UTF-8 and UTF-16?
UTF-8 encodes each character 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 text into a consistent representation so that visually identical strings 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.
What is a Unicode block and why does it matter?
A Unicode block is a named, contiguous range of code points grouped by script or purpose, such as Basic Latin or CJK Unified Ideographs. Knowing a character’s block helps identify its origin and expected usage, which is useful when debugging unexpected characters in a dataset.