A Unicode scalar value is the single abstract integer the Unicode Standard assigns to each assigned character, and the Unicode Encoder / Decoder exposes every scalar in your string by running entirely in your browser — no char code lookup API call, no server round-trip, and no upload. The tool walks through your input by Unicode code point rather than by JavaScript UTF-16 code unit, which is the key difference that lets it expose 😀 as the single token U+1F600 instead of splitting it into two surrogate halves. It then formats basic characters with at least four hexadecimal digits — A becomes U+0041 — while supplementary-plane characters keep their full numeric value. The conversion happens locally in the browser, so it works once the page is loaded and avoids any privacy concern about sending pasted text to a remote endpoint. This makes it a practical alternative to a hosted char code lookup API for developers who need to inspect a string, diagnose why a copy-paste comparison fails, or rebuild text from scalar tokens captured in logs or documentation.
Why run a char code lookup locally instead of calling an API
A hosted char code lookup API takes your string, sends it over the network, and returns one or more code identifiers. That works, but it introduces friction: you need an API key, you depend on the service being online, you pay for the round-trip latency on every keystroke, and you have to trust the endpoint with whatever text you are inspecting — which can be a real concern when that text is a customer record, a secret token, or a snippet copied from a private document.
A browser-based converter sidesteps every one of those issues. The conversion in the Unicode Encoder / Decoder runs locally: paste a string, click convert, and the result appears without leaving the page. There is no account, no quota, no API key, and no risk of leaking the characters you are trying to debug. The same is true when you reverse the operation and feed in U+XXXX or \u{...} tokens to rebuild the original text.
This is exactly the gap that the "API alternative" framing is meant to fill: you still want the deterministic, standards-backed answer a char code lookup API provides, but you want it without a network dependency, a signup, or an upload of the string you are about to inspect.
Encode text to Unicode code points
- Choose the text-to-code-points direction and paste the exact string you want to inspect, including characters you cannot see — newlines, tabs, zero-width joiners, and BOM markers all count.
- Convert and read the result: a sequence of U+ hexadecimal labels, one per Unicode scalar value, formatted in uppercase with a four-digit minimum for basic characters.
- Copy the U+ sequence and compare it against what a library, log line, or regex pattern expects; if the visible output looks identical but the U+ sequence differs, the mismatch is usually a normalization difference, an invisible control character, or a missing joiner.
A few fixtures illustrate the output you can expect:
- The single ASCII letter A becomes U+0041.
- The accented character é in its precomposed form becomes U+00E9.
- The supplementary-plane emoji 😀 becomes U+1F600, not the surrogate pair D83D DE00 that a JavaScript UTF-16 iteration would produce.
- A newline encodes as U+000A; a zero-width joiner appears explicitly as U+200D.
Decode U+XXXX or \u{...} tokens back to text
When the data flow is reversed, paste a list of prefixed tokens into the decode direction. The accepted formats are U+XXXX (four or more hexadecimal digits), \uXXXX (JavaScript-style escape), and \u{XXXX} or \u{XXXXX} (JavaScript brace notation for supplementary values). Tokens may be separated by spaces, commas, or line breaks. Hexadecimal digits are case-insensitive, but you must keep the prefix and the token boundaries intact — two adjacent tokens without a separator can otherwise be read as one longer hexadecimal number.
The tool validates every token before reconstructing any output. It rejects values outside U+0000 through U+10FFFF, it rejects the surrogate range U+D800 through U+DFFF, it rejects missing prefixes, and it rejects any non-hexadecimal character. The output text is built only after every token has passed scalar-value validation, so you see an explicit error rather than silently corrupted characters. That strictness avoids the common self-consistency trap in which a wrong surrogate convention round-trips with itself and never surfaces a warning.
Code points, UTF-16 units, and UTF-8 bytes are three different things
A code point is not a byte, and it is not a JavaScript character. Confusing these three layers is the most common reason a "char code lookup" gives the wrong answer for non-ASCII text.
| Representation | What it identifies | Example for é | Example for 😀 |
|---|---|---|---|
| Unicode code point (U+) | The abstract character per the Unicode Standard | U+00E9 | U+1F600 |
| UTF-16 code unit | A 16-bit value used by JavaScript strings, .NET, Windows APIs | 00E9 (one unit) | D83D DE00 (two surrogate halves) |
| UTF-8 byte | An 8-bit value used by files, URLs, JSON, HTTP, most network protocols | C3 A9 | F0 9F 98 80 |
If a tool reports the value for 😀 as 128512, that is the decimal form of U+1F600 and you are working at the code-point layer, the same layer the Unicode Encoder / Decoder targets. If it reports 55357 56832, those are two UTF-16 code units. If it reports F0 9F 98 80, those are four UTF-8 bytes. All three descriptions are correct for their own layer; cross them and the numbers look incompatible. The published Unicode Code Charts list the abstract characters, while ECMAScript String.fromCodePoint defines the code-point constructor used by the JavaScript runtime. When a protocol, file format, or storage layer demands bytes rather than scalars, switch to the UTF-8 byte converter.
Real-world strings are rarely a one-to-one match between visible characters and code points
A code point is not necessarily a user-perceived character. The emoji 👩💻 (woman technologist) is a sequence of three code points — U+1F469 (woman), U+200D (zero-width joiner), and U+1F4BB (laptop) — and renders as a single grapheme. Many flags, family emoji, accented letters, and writing-system forms use the same kind of multi-scalar sequence. The table below shows how a few common inputs actually break down.
| Visible character or string | Scalar sequence |
|---|---|
| A | U+0041 |
| é (precomposed) | U+00E9 |
| é (decomposed) | U+0065 U+0301 |
| 😀 | U+1F600 |
| 👩💻 | U+1F469 U+200D U+1F4BB |
| newline | U+000A |
| ♪ (musical symbol) | U+266A |
The two é rows look identical when rendered, and both are valid Unicode, but their scalar sequences differ. That difference is exactly what you need to surface when a search query, an identifier, a filename, or a comparison is failing for no apparent reason. The Unicode Encoder / Decoder exposes this without performing normalization, so what you paste in is what gets decoded. Control characters and default-ignorable code points are also included, which is why a zero-width joiner appears explicitly as U+200D and a newline as U+000A — revealing the invisible values that explain unexpected cursor movement or why text pasted from another source fails an exact comparison.
Where this tool stops and another tool takes over
The U+ representation is a diagnostic format, not an escape for every programming language. HTML entities use &...; or &#...;, JSON uses \uXXXX inside string literals, URL encoding uses %XX per byte, and UTF-8 uses raw bytes. Each of those has its own syntax and its own rules, and none of them are produced by inspecting Unicode scalar values. Use the Unicode Encoder / Decoder when your real question is which abstract characters a string contains. Use the UTF-8 byte converter when a protocol or file format demands byte-level encoding, and use the HTML entity encoder, the URL decoder, or the JSON-style escape of your runtime when you need a specific escape syntax. Keeping scalar inspection as the ground truth for character identity lets you switch between those encodings without losing track of what the original string actually said.
The tool also has a small, explicit limit: input is capped at 100,000 code points so rendering and copying stay responsive. It does not look up character names, scripts, confusable status, or language meaning, and it does not validate whether a sequence forms a recommended emoji ZWJ sequence or a single orthographic cluster. Those are separate Unicode properties beyond reversible scalar conversion, and treating them as out of scope is what lets the tool stay focused and trustworthy as a local char code lookup alternative.