A Unicode code point is a single number from U+0000 to U+10FFFF that identifies one abstract character, and a char code lookup cheat sheet is the shorthand reference that maps each character to its hexadecimal label and back. The two notations a developer sees most often are U+XXXX — the official Unicode standard format — and \uXXXX or \u{XXXXX}, which is the JavaScript-style escape with brace notation reserved for supplementary values. Basic characters resolve to a minimum of four hexadecimal digits, so the letter A becomes U+0041, while supplementary characters keep their full value and 😀 surfaces as U+1F600 instead of being split into two UTF-16 surrogate halves. A working cheat sheet therefore has to cover token prefixes, accepted separators, the surrogate exclusion interval U+D800 through U+DFFF, and the rule that one visible glyph such as 👩💻 can encode to several scalars. The rest of this article lays out that reference and shows how a browser-based Unicode Encoder / Decoder verifies any string against the rules without sending data to a server.
Cheat Sheet: The Core Code Point Formats
Three notations appear in almost every codebase, log file, or Unicode reference page. They are not interchangeable: each one has its own prefix, accepted separator set, and rules about how supplementary values are written. Memorising the differences is the first step in any char code lookup.
| Notation | Example | Where it appears | Notes |
|---|---|---|---|
| U+XXXX | U+0041 | Unicode Standard, code charts, documentation | Minimum four hex digits; uppercase or lowercase hex |
| \uXXXX | \u0041 | JavaScript, Java, C#, JSON string escapes | Exactly four hex digits; surrogate halves are common here |
| \u{XXXXX} | \u{1F600} | JavaScript template literals, modern ECMAScript | One to six hex digits; required for supplementary values |
| HTML numeric entity | 😀 | HTML and XML documents | Decimal or hex with &#x...; prefix; different grammar from U+ |
The U+ prefix is the canonical identifier that appears in the Unicode Code Charts, and the brace form \u{...} is the only JavaScript escape that can carry a five- or six-digit supplementary value in a single token. HTML entities use a separate grammar rooted in decimal or hex with an ampersand prefix, so they belong on a different reference page.
How to Look Up a Character Code
The workflow below works whether you are debugging a copied string, validating documentation, or building test fixtures. The Unicode Encoder / Decoder runs locally, so pasted text never leaves the browser.
- Choose the encode direction and paste the exact text you want to inspect, including invisible characters such as zero-width joiners, non-breaking spaces, or trailing newlines.
- Run the conversion and read each U+ token in the output. Each token is one Unicode scalar value, not necessarily one visible character.
- Copy the U+ sequence for documentation, debugging notes, or to feed back into a test case. Basic characters appear with at least four hexadecimal digits, and supplementary characters keep their full numeric value rather than splitting into two surrogate halves.
- To go the other way, switch to decode mode and enter prefixed tokens such as U+1F600, \u0041, or \u{1F600}. Tokens can be separated by spaces, commas, or line breaks.
- Confirm every token parses as a valid scalar — values from U+0000 through U+10FFFF except U+D800 through U+DFFF — before the tool produces output. Surrogate halves, out-of-range numbers, missing prefixes, and non-hex characters are rejected instead of silently replaced.
Input size is capped at 100,000 code points so the result panel stays responsive while you scroll, copy, and compare. That ceiling covers typical debugging snippets, log lines, and test fixtures, but it excludes full-file dumps that should be split or filtered before pasting.
Supplementary Characters and the Surrogate Gap
The Unicode scalar range runs from U+0000 to U+10FFFF, but the interval U+D800 through U+DFFF is excluded. That window of 2,048 values is reserved for UTF-16 surrogate code units, which always travel in pairs to address the supplementary plane. A char code lookup cheat sheet has to flag this exclusion because legacy JavaScript code that uses \uD83D\uDE00 produces the same string as \u{1F600}, but only the latter is a clean scalar representation.
| Range | Plane or block | Notes |
|---|---|---|
| U+0000 to U+007F | Basic Latin (ASCII) | 7-bit; always single-byte in UTF-8 |
| U+0080 to U+00FF | Latin-1 Supplement | Includes precomposed é at U+00E9 |
| U+0100 to U+FFFF | Basic Multilingual Plane | Most modern scripts live here |
| U+D800 to U+DFFF | Surrogates (excluded) | UTF-16 pairs only; never standalone scalars |
| U+10000 to U+10FFFF | Supplementary planes | Includes 😀 at U+1F600; requires brace notation in JS |
The Unicode Encoder / Decoder iterates code points rather than UTF-16 code units, so 😀 renders as the single token U+1F600. Decode mode enforces the surrogate exclusion: pasting \uD800 alone returns an error rather than a replacement glyph. That validation matters when comparing strings, since a stray surrogate half and its matching pair both decode to the same UTF-16 result but only one of them is a clean scalar representation.
One Glyph, Many Code Points
A code point is not the same thing as a user-perceived character. The woman-and-laptop emoji 👩💻 is the sequence U+1F469, U+200D, U+1F4BB — a woman, a zero-width joiner, and a laptop — and the tool reports all three tokens in order. Family emoji, skin-tone modifiers, regional indicator flags, accented Latin forms such as é written as U+0065 U+0301 instead of U+00E9, and many CJK characters follow the same multi-code-point pattern.
Normalization is intentionally not performed: the precomposed form U+00E9 and the decomposed form U+0065 U+0301 both render as é but compare unequal byte-for-byte. Keeping that exactness is what makes code-point inspection useful for diagnosing search, identifier, filename, and equality problems where two strings look identical on screen yet fail an exact comparison. The page displays the scalar sequence and does not claim to segment grapheme clusters, so users still need a grapheme-aware library when the question is where one visible character starts and ends.
Decode vs Encode: Choosing a Direction
The cheat sheet applies to both directions, but the workflow differs. Encode mode answers the question "which abstract characters does this string contain?" and is the right tool when you have copied text from a browser, a database, or a screenshot and need to know exactly what is in it, including control characters and default-ignorable code points. A newline encodes as U+000A and a zero-width joiner appears explicitly as U+200D, which explains unexpected cursor movement or invisible differences between two pasted strings.
Decode mode answers the complementary question "what text does this sequence of tokens represent?" and is the right tool when documentation, log output, or source code already gives you scalar labels. Preserve the prefix on every token and keep a separator between adjacent values — without a space, U+0041U+0042 can be mistaken for one longer hexadecimal number rather than two characters. Hexadecimal is case-insensitive, so U+0041 and u+0041 decode to the same letter.
Where Code Point Lookup Stops and Bytes Begin
Unicode code points and UTF-8 bytes are not interchangeable. U+00E9 identifies the character é, while its UTF-8 representation is the two bytes C3 A9. When a protocol, file format, or wire format requires byte-level encoding — HTTP headers, JSON, source files, or database columns — the byte view is what matters. The code-point view stays as the ground truth for character identity: it tells you which abstract characters the string contains, not how those characters happen to be serialized on disk.
Other representations — HTML entities, JSON \u escapes, URL percent-encoding, Base64 — all carry their own syntax and rules. Treat code point inspection as the canonical reference for what a character is, then choose the consuming system's required representation for transport. The output of this tool is a diagnostic view, not a transport encoding, and it does not look up character names, scripts, confusable status, or language meaning, nor does it validate whether a sequence forms a recommended emoji or orthographic cluster — those are separate Unicode properties beyond reversible scalar conversion.
A quick way to remember the boundary: code points describe what a character is, while bytes describe how it travels. When debugging a database column, a JSON payload, or a filename, decide which view the receiving system expects first, then map back to the code-point level only when you need to confirm the abstract identity of the characters involved.
Related reading: Decode URL Strings in Java: Code and a Browser Tool.