A char code lookup reveals every Unicode scalar value inside a string, exposing exactly which abstract characters — from U+0000 to U+10FFFF — the text contains rather than how it is stored as bytes or how it is drawn on screen. Each scalar value is a number assigned by the Unicode standard, formatted as U+ followed by uppercase hexadecimal with at least four digits, so the letter A appears as U+0041 and the grinning face emoji 😀 appears as U+1F600 instead of being split into two surrogate halves. The lookup is bidirectional: paste a string to see its code points, or paste a sequence of U+XXXX or \u{...} tokens to rebuild the original text. Because the conversion iterates Unicode code points rather than JavaScript UTF-16 code units, supplementary-plane characters stay as single scalar values, control characters and zero-width joiners are exposed explicitly, and surrogate code units in the U+D800 through U+DFFF range are rejected instead of silently passed through. This is the ground-truth view of character identity that every other text encoding builds on.
What a Char Code Lookup Actually Shows
At its core, a char code lookup answers a single diagnostic question: which abstract characters does this string contain? The answer is a list of scalar values, each one a unique integer between 0 and 1,114,111, written as U+ plus the value in hexadecimal. The output is deterministic and loss-free for any Unicode string. The letter A becomes U+0041, the lowercase é becomes U+00E9, the CJK character 中 becomes U+4E2D, and the emoji 😀 becomes U+1F600. Basic characters receive at least four hex digits, while supplementary-plane characters keep their full value rather than being split into two surrogate halves as JavaScript's UTF-16 indexing would do. The conversion iterates code points, not code units, so a paste that contains mixed scripts, accented forms, or modern emoji all resolves cleanly into a single token stream. For a quick check of mixed-language text or for debugging strings copied from another program, the Unicode Encoder / Decoder produces this view directly in the browser.
Why a Code Point Is Not the Same as a Character
The most common source of confusion in a char code lookup is the assumption that one code point equals one visible character. It does not. Unicode scalar values are an abstract numbering; the way a user perceives a character on screen is a separate concept called a grapheme cluster, and a single grapheme can require several scalar values. The emoji 👩💻 (woman technologist) is a clear example: it is encoded as the sequence U+1F469 (woman), U+200D (zero-width joiner), and U+1F4BB (laptop). Three scalar values, one visible symbol. The same pattern applies to many family emoji, regional flags joined by invisible separator code points, accented forms that can be written either as a single precomposed character or as a base letter plus a combining mark, and writing systems that use combining diacritics. A char code lookup displays the scalar sequence and does not claim to segment grapheme clusters — the two are layered views of the same text, and both are useful for different kinds of work.
The Scalar Range and Surrogate Exclusion
Unicode assigns scalar values across seventeen planes, beginning at U+0000 in the Basic Multilingual Plane and ending at U+10FFFF at the top of Plane 16. Within that range, the interval from U+D800 through U+DFFF is permanently reserved for UTF-16 surrogate pairs and never identifies a standalone character. A correct char code lookup enforces both bounds: it rejects surrogate halves because they only have meaning when paired, and it rejects anything above U+10FFFF because no value outside the scalar range is defined by the standard. Validation is not cosmetic. The Unicode standard defines the rules for how scalar values become the byte sequences used in UTF-8, UTF-16, and other encodings, and those rules assume the surrogate range is empty. A tool that silently passed surrogate values through would let a malformed string round-trip with itself while still being rejected by every standards-compliant decoder downstream. The standard's code point charts at unicode.org/charts document the full assignment, and a scalar-only view stays inside that documented contract.
Code Point vs UTF-8 Byte
Because both terms use the word "encoding," code points and UTF-8 bytes are routinely conflated. They answer different questions. A code point names an abstract character; a UTF-8 byte sequence is one concrete on-the-wire representation of that character. The relationship between them is fixed by the standard, so a small table is enough to make the distinction concrete.
| Character | Unicode scalar | UTF-8 bytes |
|---|---|---|
| A | U+0041 | 41 |
| é (precomposed) | U+00E9 | C3 A9 |
| 中 | U+4E2D | E4 B8 AD |
| 😀 | U+1F600 | F0 9F 98 80 |
| newline | U+000A | 0A |
For ASCII characters, the scalar value and the single UTF-8 byte happen to match. For anything outside ASCII, they diverge by design, and the gap widens sharply for supplementary characters. When the question is "which abstract characters are in this string," the scalar view is the right one. When the question is "what bytes does this file or protocol actually carry," a UTF-8 byte view is the right one.
Run a Char Code Lookup in Your Browser
For a quick diagnostic pass on a string, the encoder mode of a scalar-aware tool is enough. The procedure keeps the input and the output unambiguous, even when invisible characters are involved.
- Open the Unicode Encoder / Decoder and select the text-to-code-points direction.
- Paste the exact string you want to inspect, including any invisible characters such as spaces, tabs, newlines, or zero-width joiners. The tool limits input to 100,000 code points, so very long strings may be truncated to keep rendering and copying responsive. Do not retype the text from memory — copy it from the source so the byte sequence stays intact.
- Convert and inspect each U+ token. Confirm that supplementary characters appear as a single scalar value, for example 😀 as U+1F600, rather than as a surrogate pair.
- Read the token stream as a diagnostic. A surprise newline (U+000A) at the end of a pasted identifier, a stray U+200D between two visible characters, or a non-breaking space (U+00A0) where an ordinary space was expected will all show up here even when the rendered text looks identical.
- Copy the U+ sequence for use in logs, bug reports, or test fixtures. The scalar stream is a stable, copy-paste-safe description of the string's contents.
A worked example makes the format concrete. The capital letter A is a single code point with a hexadecimal value of 0x41. Using the standard hex-to-decimal conversion, 0x41 equals 4 × 16 + 1, which is 65 in decimal. The lookup therefore reports U+0041 — uppercase A, basic Latin, decimal 65. Once that one conversion is understood, the same logic applies to every other scalar value in the string.
Decode U+ and \u{} Tokens Back Into Text
Logs, documentation, and source code frequently contain scalar values rather than the original characters. The reverse direction of the same tool rebuilds the string from those tokens. Each token must begin with U+ (for example U+0041 or U+1F600) or with the JavaScript-style backslash-u notation \u0041 or \u{1F600}, including the brace form required for supplementary values. Tokens can be separated by spaces, commas, or line breaks, and hexadecimal letters are case-insensitive, so u+0041 and U+0041 are equivalent. The tool validates every token before constructing the output: out-of-range numbers, missing prefixes, non-hexadecimal characters, and any value in the surrogate range are rejected rather than silently replaced. The output is built only after the full token list passes scalar validation, which is why a malformed token is reported as a single error instead of corrupting the result. A practical reference for the two token forms is the U+XXXX and \u{} syntax cheat sheet.
When Code Point Inspection Is the Wrong Tool
Unicode code points are the ground truth for character identity, but they are not a universal text format. A char code lookup deliberately does not normalize input, so a precomposed é (U+00E9) and a decomposed é (U+0065 followed by U+0301) are treated as different sequences even though they usually render alike. That exactness is the point for diagnostics, but it is the wrong tool for tasks that require a specific wire format. HTML entities, JSON string escapes, URL percent-encoding, and UTF-8 bytes all have their own syntax and rules, and the right choice depends on the consuming system rather than on the abstract character. When a protocol, a file format, or a programming language mandates one of those representations, use the matching converter and keep code point inspection for the question it actually answers: which abstract characters are in this string.
Related reading: ASCII Code Converter Explained: Characters and Their Codes.