A char code lookup answers one question in plain numbers: which Unicode scalar value identifies each character in a string? Every printable letter, every accented form, every emoji, and every invisible control character such as a newline or a zero-width joiner has a code point written as U+ followed by at least four hexadecimal digits, with valid values running from U+0000 through U+10FFFF. The Unicode Encoder/Decoder converts a string into that exact U+ sequence locally in your browser, and converts validated U+XXXX or \u{...} tokens back into text without sending anything to a server. For a beginner, this is a direct way to see what a string really contains, because two strings that look identical on screen can carry different sequences once invisible code points are exposed.
What a Character Code Actually Is
A character code is a single integer assigned to one abstract character by the Unicode Standard. The hexadecimal form is the familiar U+XXXX notation, where XXXX is at least four digits and uses the digits 0 through 9 and A through F. Capital A is U+0041, the digit 9 is U+0039, and a space is U+0020. Every code point falls in the range U+0000 through U+10FFFF, which gives roughly 1.1 million possible values.
One number identifies one Unicode scalar value. That single value can render as a letter, a digit, a punctuation mark, a CJK character, a musical symbol, an historical script letter, or a single emoji glyph. The relationship between a code point and what you see on screen is direct for most characters, but the rule breaks for emoji that are built from several scalars joined by U+200D, the zero-width joiner. That is why a beginner can run a lookup, see a list of five U+ tokens for one visible emoji, and reasonably wonder what went wrong. Nothing went wrong; the tool is showing exactly what the string contains, one scalar at a time.
The tool refuses values in the range U+D800 through U+DFFF during decode. That range is reserved for UTF-16 surrogate code units, which only exist as halves of a pair and do not identify standalone characters. Treat the U+D800 through U+DFFF exclusion as the difference between a character and one half of a character pair. For a beginner who only writes U+XXXX tokens, this rarely comes up, but it explains why random hex strings sometimes get rejected.
Your First Char Code Lookup
To run a lookup on a small piece of text, follow these steps.
- Open the Unicode Encoder / Decoder and choose the text-to-code-points mode.
- Paste the exact characters into the input box, including invisible ones such as a trailing newline or a zero-width joiner if you suspect one is present.
- Press Convert and read the U+ token list that appears below. Each token is one Unicode scalar value in the string.
- Copy the token list if you need to share it, paste it into a search, a log, or a test.
- To go the other way, switch to the decode mode and enter U+XXXX or \u{XXXX} tokens separated by spaces, commas, or line breaks, then run Convert to rebuild the text.
The tool runs entirely in your browser, so pasted text never leaves your machine. The conversion iterates by Unicode scalar value rather than JavaScript UTF-16 code units, which means supplementary characters keep their full numeric value instead of being split into two surrogate halves. The practical upshot is that 😀 shows up as the single token U+1F600 rather than the awkward pair U+D83D U+DE00 that some older scripts produce.
Reading the U+ Output
Each line of the result is one scalar value, formatted with a four-digit minimum in uppercase hexadecimal. The input "A" gives the single token U+0041. The string "ABC" gives U+0041 U+0042 U+0043, with no separator needed between adjacent values because every token starts with U+. A newline in the input becomes U+000A, and a tab becomes U+0009. The tool intentionally includes control characters and default-ignorable code points rather than hiding them, because the most common reason a beginner needs a char code lookup is to find an invisible mismatch.
Case in hex digits does not matter, since U+00E9 and u+00e9 are the same scalar. The decimal equivalent is helpful when comparing with programming languages, and the conversion is one small step. For example, U+1F600 breaks down as follows:
0x1F600 = (1 × 16⁴) + (F × 16³) + (6 × 16²) + (0 × 16) + 0 = (1 × 65536) + (15 × 4096) + (6 × 256) + 0 + 0 = 65536 + 61440 + 1536 + 0 + 0 = 128,512
That decimal value is the code point for 😀, the grinning face emoji. The same scalar identified in three different notations, U+1F600 in hex, 128512 in decimal, and \u{1F600} in JavaScript brace form, points to one and only one character.
One Visible Symbol, Several Code Points
This is the single most common surprise for new users. A grapheme cluster, the thing a reader perceives as one character, is not always one Unicode scalar value. The woman-technologist emoji 👩💻 is a sequence of three code points joined by a zero-width joiner.
| Component | Code point | Meaning |
|---|---|---|
| 👩 | U+1F469 | Woman |
| Invisible joiner | U+200D | Zero-width joiner |
| 💻 | U+1F4BB | Laptop |
Many flags, family emoji, accented letters written in pieces, regional indicator pairs, and skin-tone modified emoji all behave the same way. Two glyphs that render identically can have completely different scalar sequences, which is exactly why a character code lookup returns what it returns and not one number per visible letter.
Code Points Are Not UTF-8 Bytes
A code point names a character. UTF-8 names how that character is stored as bytes. They are different layers, and confusing them is a classic beginner trap. The same string of code points can be serialized as UTF-8, UTF-16, or UTF-32, with different byte counts and different byte values.
| Character | Unicode code point | UTF-8 bytes |
|---|---|---|
| A | U+0041 | 41 |
| é | U+00E9 | C3 A9 |
| 中 | U+4E2D | E4 B8 AD |
| 😀 | U+1F600 | F0 9F 98 80 |
| 👩💻 (three scalars) | U+1F469 U+200D U+1F4BB | F0 9F 91 A9 E2 80 8D F0 9F 92 BB |
When a protocol or file format talks about bytes, it is talking about the rightmost column. When it talks about characters, it is talking about the middle column. For a byte-level view, use a separate UTF-8 byte converter, since this tool is built for the question of which abstract characters a string contains. For deeper character-name lookups once you have a code point, the official Unicode Code Charts provide the canonical names and blocks.
Decoding U+ Tokens Back Into Text
Decode mode is the mirror of encode mode. Paste a list of tokens and the tool rebuilds the corresponding text. Tokens must begin with U+ or use the JavaScript-style backslash-u form, including brace notation for supplementary values. Spaces, commas, and line breaks all work as separators. Hexadecimal is case-insensitive.
Valid examples that decode cleanly:
- U+0048 U+0069 → Hi
- U+00E9, U+0065 → é, e (one precomposed accented letter and one plain letter)
- \u{1F600} → 😀
- U+1F469 U+200D U+1F4BB → 👩💻
Examples that the tool rejects, by design:
- U+D800 — surrogate half, not a standalone character
- U+110000 — out of range, above U+10FFFF
- 1F600 — missing the U+ prefix
- U+GGGG — non-hexadecimal characters
This rejection behavior is deliberate. A wrong surrogate convention round-trips with itself and silently produces wrong text, so the tool fails loudly instead of substituting plausible-looking garbage. The trade-off is fewer magic recoveries, and the benefit is that every decoded string comes from validated Unicode scalar values. For a fuller reference on the syntax, the Char Code Lookup Cheat Sheet walks through every accepted form.
Invisible Characters That Change Your String
Beginner lookups often start with a string that misbehaves. A search field rejects text that should match. A filename fails to compare. Cursor position is off by one. A character code lookup frequently explains all three.
A newline encodes as U+000A. A carriage return encodes as U+000D. Windows line endings are the two-scalar sequence U+000D U+000A, which looks identical to U+000A on Unix but compares as a different string. A zero-width joiner appears explicitly as U+200D. A byte-order mark appears as U+FEFF. A no-break space appears as U+00A0 and looks like a regular U+0020 space until you copy it elsewhere.
Normalization is intentionally not performed. The precomposed é is U+00E9. The visually identical but technically different decomposed form is the two-scalar sequence U+0065 U+0301, plain e followed by a combining acute accent. Both render the same in most fonts, and both are valid Unicode. They are also different scalar sequences, so a strict equality check will see them as different strings. Exposing the actual code points makes that difference visible, which is the whole point of a char code lookup.
The tool caps input at 100,000 code points to keep the copy and render step responsive, and it does not look up character names, scripts, confusable status, or language meaning. Those properties live outside reversible scalar conversion. For raw scalar inspection, though, this is the ground truth.
If you're weighing options, ASCII Code Converter for Beginners: A Plain-English Start covers this in detail.