Unicode Character Lookup
Search Unicode characters by glyph, code point, name, script or block.
Inspect code points, Unicode names, scripts, categories, UTF-8 bytes, escapes and normalization details for every character.
Your text is processed in this browser and is not submitted to UnicodeNow.
Primary flow: character → code point → Unicode name → category → script → encoding → normalization context.
The built-in example is cafe\u0301\u00A0👨👩👧👦.
Enter text to inspect its Unicode characters.
Choose a comparison form to inspect sequence-level normalization changes.
| Position | Character | Code point | Unicode name | Category | Script | UTF-8 bytes | UTF-16 units | Escape | HTML entity | Properties | Actions |
|---|
No rows to show yet.
The Unicode Character Inspector shows each Unicode code point in your input, including the displayed character or token, code point, Unicode name, general category, script, block, UTF-8 bytes, UTF-16 units, JavaScript and Python escapes, HTML numeric entities, normalization details and grapheme-cluster relationships.
A visible character is not always one code point. The letter é may be a single composed code point or the sequence e plus a combining acute mark. Emoji can use zero-width joiners, skin-tone modifiers or regional indicators. The table keeps every code point inspectable instead of hiding these details.
UTF-8 stores Unicode code points as one to four bytes. JavaScript strings use UTF-16 code units, so supplementary-plane characters such as many emoji occupy two UTF-16 units even though they are one code point. This is why byte length, JavaScript string length and user-perceived character count may differ.
Grapheme clusters approximate user-perceived characters and may contain multiple code points. This tool uses the browser's Intl.Segmenter when available. Browser segmentation follows the local implementation and should be treated as a practical diagnostic, not a promise that every environment segments identically.
Normalization is shown as a diagnostic comparison. NFC, NFD, NFKC and NFKD can change code-point sequences, but the inspector does not replace your input. For e\u0301, NFC compares the original sequence U+0065 U+0301 with U+00E9. Compatibility forms can be useful for selected matching and search workflows, but may lose formatting distinctions.
Spaces, non-breaking spaces, zero-width characters, controls, joiners, variation selectors and bidi controls may not be visually obvious. The inspector labels them with tokens such as ⟦NBSP⟧, ⟦ZWJ⟧ or ⟦RLO⟧ while preserving the real input and report values.
The example cafe\u0301\u00A0👨👩👧👦 contains decomposed accented text, a no-break space, supplementary-plane emoji and zero-width joiners. It demonstrates code points versus grapheme clusters, invisible tokens, UTF-8 bytes, UTF-16 surrogate pairs and normalization analysis.
Inspection runs locally in JavaScript using Unicode-aware code-point iteration, TextEncoder, UTF-16 code-unit inspection, String.prototype.normalize(), browser grapheme segmentation when available, and compact local Unicode metadata. No input is sent to a metadata API.
Your text remains in this browser. It is not uploaded, stored, inserted into URLs or sent through analytics.
A Unicode code point is a numeric value assigned by Unicode, usually written as U+ followed by hexadecimal digits.
A visible character can be one code point or a sequence of code points, such as a base letter plus a combining mark or an emoji sequence.
JavaScript strings use UTF-16 code units. Supplementary-plane code points such as many emoji use two UTF-16 code units.
A grapheme cluster approximates one user-perceived character and may contain several Unicode code points.
It can be stored as U+00E9 or as U+0065 followed by U+0301 COMBINING ACUTE ACCENT; normalization can compare these sequences.
UTF-8 stores code points as one to four bytes. UTF-16 stores them as one or two 16-bit code units.
General categories classify code points, such as uppercase letters, lowercase letters, marks, spaces, controls and symbols.
A script groups characters used by a writing system, such as Latin, Cyrillic, Arabic or Han. Common punctuation and emoji often use Common or Inherited.
They are Unicode normalization forms. NFC and NFD are canonical forms; NFKC and NFKD also apply compatibility mappings.
Some code points represent spacing, controls, joining behavior, variation selection or direction rather than a visible glyph.
No. They can be accidental or suspicious in some contexts, but ZWJ and ZWNJ are legitimate in emoji and writing systems.
Yes. It shows each code point and, when the browser supports Intl.Segmenter, the grapheme cluster that groups the sequence.
No. Inspection runs in this browser. Input is not uploaded, stored, placed in URLs or sent through analytics.
Search Unicode characters by glyph, code point, name, script or block.
Analyze code points, grapheme clusters, bytes, scripts and directionality.
Find zero-width, control, variation, private-use and spacing characters.
Normalize Unicode text to NFC, NFD, NFKC or NFKD.
Convert text into U+XXXX Unicode code point notation.
Convert U+XXXX, 0x, and escape-style code points back to text.
Detect Unicode confusables, scripts, skeleton matches and suspicious lookalike patterns.
Unicode is the international standard used to represent text consistently across computers, phones, websites, programming languages and operating systems.
Learn how zero-width spaces, joiners, non-breaking spaces, bidi controls and other invisible Unicode characters affect text.
A safe workflow for detecting, previewing and removing unwanted zero-width Unicode characters without breaking emoji or language text.
Compare literal Unicode characters, named HTML entities, numeric character references, code points and UTF-8 bytes.