Unicode Character Lookup
Inspect a character or escape and compare its U+ value with UTF encodings and normalization forms while revealing invisible text and grapheme structure.{{ summaryTitle }}
{{ summaryLine }}
{{ referenceExportStatus }}
- {{ row.label }}
- {{ row.value }}
- {{ note }}
{{ chartExportStatus }}
The chart renderer is unavailable. The exact counts remain in the reference and exported JSON.
{{ tableExportStatus.copy_targets || '' }}
| Target | Output | Use | Copy |
|---|---|---|---|
| {{ row.target }} | {{ row.output }} | {{ row.note }} |
{{ tableExportStatus.normalization_preview || '' }}
| Form | Preview | U+ | Change | Copy |
|---|---|---|---|---|
| {{ row.form }} | {{ row.preview }} | {{ row.code_points }} | {{ row.change }} |
{{ tableExportStatus.sequence_audit || '' }}
| # | Preview | Name | U+ | Type | Script | Copy |
|---|---|---|---|---|---|---|
| {{ row.position }} | {{ row.preview }} | {{ row.name }} | {{ row.u_plus }} | {{ row.type }} | {{ row.script }} |
A character that looks ordinary can have several valid machine representations. The visible letter é may be one code point or a sequence containing e followed by a combining accent. An emoji may join several people, objects, modifiers, or variation selectors into one visible symbol. A space-like mark may occupy no visible width at all.
Unicode assigns code points, written in forms such as U+2713, but code points are not bytes and do not always match what a reader counts as one character. UTF-8 encodes a scalar value as one to four bytes. UTF-16 uses one 16-bit code unit for values in the Basic Multilingual Plane and a surrogate pair for supplementary values. Text editors, programming languages, style sheets, HTML, and URLs then add their own escape syntax around those values.
- Code point
- A numbered Unicode value from
U+0000throughU+10FFFF. - Unicode scalar value
- A code point outside the surrogate range
U+D800throughU+DFFF. - Grapheme cluster
- A sequence that people usually perceive as one character, even when it contains several code points.
- Normalization
- A defined conversion between canonically or compatibly related code-point sequences.
These distinctions explain many “looks the same but does not match” bugs. Database keys can differ after a composed/decomposed change. An invisible format character can survive copying. A private-use character can display correctly only with the originating font or application agreement. A lone surrogate can exist in a UTF-16-oriented runtime yet cannot be encoded as well-formed UTF-8.
Normalization helps compare or standardize text, but it is not a security filter. NFC and NFD preserve canonical equivalence while choosing composed or decomposed forms. NFKC and NFKD also apply compatibility mappings, which can change distinctions that matter to identifiers, source code, or specialized notation.
How to Use This Tool:
Choose a pinned interpretation when digits, backslashes, or percent bytes could be read more than one way.
- Select Interpret input as. Auto detect is convenient for obvious values; use a specific code-point, JavaScript, CSS, or percent-UTF-8 mode when syntax is ambiguous.
- Enter one literal grapheme or an explicit sequence. Code-point notation accepts forms such as
U+2713,0x2713, decimal values, and numeric HTML references. - Choose NFC, NFD, NFKC, or NFKD only when a normalization comparison is needed. None leaves the inspected sequence unchanged.
- Run Inspect character, then compare the U+ sequence, encoding units, normalization rows, and any review notes before copying a representation.
Interpreting Results:
The U+ sequence is the clearest portable identity for diagnostics. Use the literal preview only as a visual clue because fonts can hide missing glyphs, combining behavior, or format controls. Compare UTF-8 bytes when investigating files, network payloads, or percent encoding; compare UTF-16 units when debugging JavaScript strings or systems that expose surrogate pairs.
- A normalization row marked Changes source means the code-point sequence changes, even if the rendered text looks the same.
- Private use is valid only under an external agreement about meaning and rendering.
- Control, Format, and Whitespace values may disappear in a visual comparison.
- A property name from fallback data may be generic. Confirm unusual or correctness-critical values against the Unicode Character Database.
Technical Details:
Input is limited to 256 UTF-16 code units. Explicit and escaped forms can inspect from 1 to 32 code points in one run. Literal mode selects the first detected grapheme and reports when later graphemes were ignored, preventing an accidental paragraph paste from becoming one oversized audit.
Transformation Core:
| Input form | Parsing rule | Intermediate result |
|---|---|---|
| Code-point tokens | U+, hexadecimal, decimal, JavaScript code-point, or numeric HTML notation | Integer code points from 0 through 0x10FFFF |
| JavaScript or JSON escapes | \u{...} uses 1–6 hex digits, \u.... uses exactly 4, and \x.. uses exactly 2 | A decoded string |
| CSS escapes | A backslash plus up to 6 hex digits; one following whitespace character terminates the escape | A decoded string |
| Percent-encoded UTF-8 | Every token must be a percent sign followed by two hex digits, and the byte sequence must decode as UTF-8 | Unicode scalar-value text |
| Literal text | The first practical grapheme segment is retained | One cluster and any ignored remainder |
Auto detection tests percent bytes first, then explicit code-point tokens, JavaScript escapes, CSS escapes, and finally literal text. Pinning a mode removes that guess. The local grapheme routine groups combining marks, variation selectors, emoji skin-tone modifiers, regional-indicator pairs, and zero-width-joiner chains; it is a practical inspector heuristic and does not cover every rule in Unicode Standard Annex #29.
Encoding Core:
UTF-8 encodes scalar values by numeric range. Surrogate code points are excluded because they are reserved for UTF-16 code-unit pairs rather than Unicode scalar values.
| Code-point range | UTF-8 bytes | UTF-16 representation |
|---|---|---|
U+0000–U+007F | 1 | One code unit |
U+0080–U+07FF | 2 | One code unit |
U+0800–U+FFFF, excluding surrogates | 3 | One code unit |
U+10000–U+10FFFF | 4 | High and low surrogate pair |
Copy targets are derived from the same resolved sequence: literal text, U+ and decimal values, JavaScript, JSON, CSS, HTML numeric references, UTF-8 bytes, percent-encoded UTF-8, UTF-16 units, and UTF-32 units. If a lone surrogate is present, UTF-8 and HTML scalar-value outputs are marked unavailable instead of substituting a replacement character.
Normalization Core:
| Form | Composition | Equivalence applied |
|---|---|---|
| NFC | Composed where defined | Canonical |
| NFD | Decomposed | Canonical |
| NFKC | Composed where defined | Canonical and compatibility |
| NFKD | Decomposed | Canonical and compatibility |
Privacy and Accuracy Notes:
The entered text is parsed in the browser. Unicode name and property data is loaded after inspection begins, but the inspected value is not included in that request. If the reference data does not load within the short wait, a small built-in reference and browser property tests supply fallback labels.
- Fallback coverage is intentionally limited, so an uncommon character may receive a generic name or approximate script/category label.
- Font rendering can make different sequences look alike or make a valid character appear missing.
- Invisible and internal-only warnings are optional review aids, not a complete spoofing or source-code security analysis.
Worked Examples:
Composed and decomposed acute accent
The precomposed U+00E9 and the sequence U+0065 U+0301 can render as the same letter. NFC composes the second form where possible; NFD decomposes the first. Comparing U+ sequences reveals the difference that a visual check can miss.
Joined emoji sequence
U+1F469 U+200D U+1F4BB contains a woman, a zero-width joiner, and a computer. It may render as one emoji grapheme while still occupying three code points, eleven UTF-8 bytes, and five UTF-16 code units.
References:
- The Unicode Standard, Chapter 3: Conformance, Unicode Consortium, Version 17.0.
- Unicode Standard Annex #15: Unicode Normalization Forms, Unicode Consortium, Revision 57.
- Unicode Standard Annex #29: Unicode Text Segmentation, Unicode Consortium, Revision 45.
- CSS Syntax Module Level 3, W3C.
- How to set UTF-8 character encoding in PuTTY, Simplified Guide.