Unicode Inspector
Inspect unicode code points, plane categories, and block details.
Unicode Inspector
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The Unicode Inspector breaks text down character by character, showing each one's Unicode code point, decimal value, and UTF-8 byte representation. Where ASCII assigns meaning to 128 values, the Unicode Standard assigns meaning to well over a million code points (U+0000 through U+10FFFF), covering essentially every script, symbol, and emoji in modern use — understanding what a specific character's code point actually is, and how it's encoded in bytes, is fundamental to debugging almost any text-processing issue that goes beyond plain English.
- Unicode code points are organized into 'planes' of 65,536 values each: the Basic Multilingual Plane (Plane 0, code points U+0000–U+FFFF) covers most modern scripts and symbols in everyday use, while emoji and several less-common scripts live in the Supplementary Multilingual Plane and beyond, at code points above U+FFFF. This plane structure is exactly why encoding a character above the BMP in UTF-16 requires a surrogate pair (see the Text to Unicode tool for that mechanism specifically) — a detail that only matters once you're working with characters outside the BMP's range.
How It Works
- Input text is decomposed character by character (using code-point-aware iteration, not naive per-UTF-16-code-unit splitting, so characters outside the Basic Multilingual Plane are handled as single units).
- Each character's code point is read and displayed in the standard U+XXXX notation used throughout the Unicode Standard and its documentation.
- The same code point's plain decimal value is shown alongside it, since some tooling and lower-level code works with decimal or raw integer code point values rather than the U+ hex notation.
- The character's actual UTF-8 byte sequence is computed and displayed — for ASCII-range characters this is a single byte; for higher code points it's 2, 3, or 4 bytes, following UTF-8's variable-length encoding scheme.
Usage
- Enter the text you want to inspect.
- Run the inspection.
- Review each character's code point, decimal value, and UTF-8 byte representation.
- Use these values to debug an encoding mismatch, confirm a specific character's identity, or calculate exact byte lengths.
Examples
- Inspecting an emoji to find its exact code point before searching Unicode Consortium documentation or a specific library's supported character list.
- Comparing the code points of two strings that look identical on screen to confirm whether they're actually composed of the same underlying characters.
- Calculating the true UTF-8 byte length of a string containing accented characters, for a system with a byte-based (not character-based) storage limit.
- Investigating a 'mojibake'-style display bug by confirming what code points a piece of text actually contains, as a first step before checking further into the Character Encoding Detector.
Real-World Use Cases
- Diagnosing why a piece of text appears differently across two systems, by inspecting whether a specific character's code point matches what both systems are expected to interpret it as.
- Determining the exact UTF-8 byte length of a string containing non-ASCII characters, when a system enforces a byte-length limit rather than a character-count limit.
- Confirming which Unicode code point a specific emoji or symbol actually corresponds to, for use in code, documentation, or a support ticket describing an encoding bug.
- Investigating whether two visually identical strings are actually composed of the same underlying code points, a common cause of 'this string doesn't match even though it looks the same' bugs.
Best Practices
- When debugging a text-length limit, confirm whether the limit is measured in characters, UTF-16 code units, or UTF-8 bytes — these three counts genuinely differ for any text containing characters outside the ASCII range, and conflating them is a common source of off-by-some-amount bugs.
- Use code-point-aware inspection (as this tool does) rather than naively splitting a JavaScript string by index, which can split a single character in the Supplementary Plane into two meaningless surrogate halves.
- Cross-reference an unfamiliar code point against the Unicode Consortium's own published character charts for its official name and script classification before assuming what it represents.
- When two strings that look identical don't compare as equal, inspect their code points directly rather than guessing — the Unicode Normalization Tool is the next step once you confirm the difference is a normalization-form mismatch.
Common Mistakes
- Splitting a JavaScript string by raw index or the naive .length property, which counts UTF-16 code units, not user-perceived characters — a single character outside the Basic Multilingual Plane occupies two code units (a surrogate pair) and can be split incorrectly this way.
- Assuming every character occupies exactly one byte, and miscalculating storage or transmission size for any text containing non-ASCII characters, which requires 2–4 bytes each in UTF-8.
- Treating two strings that render identically as guaranteed to be byte-identical, without checking whether one uses a composed and the other a decomposed Unicode representation of the same visual character.
- Confusing a code point's decimal value with its UTF-8 byte values — they are related but different numbers except for the small subset of code points (0–127) where a code point's value and its single UTF-8 byte happen to coincide.
Limitations
- This tool inspects and displays character properties; it does not modify, normalize, or re-encode the text itself — use the Unicode Normalization Tool for that.
- It reports UTF-8 byte representations specifically; other encodings (UTF-16, UTF-32, or legacy encodings) are not directly displayed, though UTF-16 code unit behavior is covered separately by the Text to Unicode tool.
- Extremely long input is processed character by character in the browser and may affect responsiveness for very large text blocks.
Technical Reference Guide
- The Unicode Standard itself, defining the full set of assigned code points, their properties, and organization into planes, is maintained by the Unicode Consortium.
- UTF-8, the encoding form this tool displays byte representations for, is defined by RFC 3629, which also confirms UTF-8's compatibility with 7-bit ASCII for code points 0–127.
- The Basic Multilingual Plane and supplementary planes structure, along with the surrogate pair mechanism needed to represent code points above U+FFFF in UTF-16, is defined within the Unicode Standard's core specification.
FAQ
What's the difference between a character's code point and its UTF-8 bytes?
The code point is the character's assigned identity in the Unicode Standard (e.g. U+00E9 for é). Its UTF-8 bytes are how that code point is actually encoded for storage or transmission — for code points above 127, this takes 2 to 4 bytes, not the single value the code point number itself might suggest.
Why does my string's .length not match the number of characters I see?
In JavaScript, .length counts UTF-16 code units, not user-perceived characters. A character outside the Basic Multilingual Plane (many emoji, for example) is represented by a surrogate pair — two code units for one visible character — inflating the count.
Why do two visually identical strings sometimes not match in an equality check?
They may use different Unicode representations of the same visual character — for example, a precomposed accented letter versus a base letter plus a separate combining accent mark. Use the Unicode Normalization Tool to resolve this to a single consistent form.
What is the Basic Multilingual Plane?
It's the first 65,536 Unicode code points (U+0000–U+FFFF), covering most modern scripts and commonly-used symbols. Many emoji and some less common scripts live in supplementary planes above this range, at code points requiring surrogate pairs in UTF-16.
Does this tool show me a character's UTF-16 representation?
It shows the UTF-8 byte representation directly; for UTF-16-specific behavior, including the surrogate pair mechanism for characters above the Basic Multilingual Plane, see the Text to Unicode tool.
Is a code point's decimal value the same as its byte value?
Only for code points 0–127, where UTF-8 encodes the code point as a single byte with the same numeric value. Above that range, a code point's decimal value and its UTF-8 byte sequence are related but different numbers.
Part of this Developer Hub
This utility is part of our comprehensive Encoding & Conversion topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Encoding & Conversion Lab workshop for complementary engineering workflows.
View all Encoding & Conversion Lab tools