Skip to main content

Unicode Escape Explained: Text to \uXXXX and Back

A practical guide to Unicode escape sequences — how \uXXXX works, why emoji split into surrogate pairs, where to use them in JSON, JS, CSS, and HTML, with a full round-trip example.

Published By Li Lei
#unicode #encoding #javascript #json #developer-tools

Unicode Escape Explained: Text to \uXXXX and Back

Sooner or later every developer hits a string they cannot type. A user named 张伟 shows up in a log as 张伟. A config file refuses raw UTF-8 and you need the Japanese label 日本語 to survive a pipeline that only speaks ASCII. A 🎉 in a CSS content property keeps getting re-encoded by your editor. The fix in all three cases is the same idea: a Unicode escape, a plain-ASCII stand-in that any text-only channel can carry and the right parser turns back into the real character.

This guide walks through what a Unicode escape actually is, why one emoji sometimes becomes two escapes, and which style belongs in JSON versus a stylesheet versus HTML markup. You can follow along in the Unicode Escape Converter, which encodes and decodes every form covered here, both directions, entirely in your browser.

What a \u escape actually is

A Unicode escape is a way to write a character using only ASCII letters and digits. The classic form is \u followed by exactly four hexadecimal digits. The concrete rule worth memorizing: each UTF-16 code unit becomes \u plus four hex digits — no more, no less. The letter A is code point U+0041, so its escape is A. The Chinese character 中 is U+4E2D, so it becomes 中. Four digits, lowercase or uppercase, always padded to four even for small values like A.

Four hex digits can represent any value from 0000 to FFFF, which covers the Basic Multilingual Plane — the first 65,536 code points, including all of Latin, Cyrillic, Greek, and the overwhelming majority of Chinese, Japanese, and Korean characters. That is why a single 中 is enough for most CJK text. The hex is just the code point number written in base 16: U+4E2D is decimal 20013, which is why the HTML entity for the same character is 中.

Why emoji split into a surrogate pair

Here is where \uXXXX shows its age. Four hex digits stop at U+FFFF, but Unicode goes far beyond that. Emoji live up in the astral planes: 😀 is U+1F600, well above the four-digit ceiling. A single \uXXXX simply cannot hold it.

JavaScript strings are stored as UTF-16, and UTF-16 encodes anything above U+FFFF as two 16-bit code units called a surrogate pair. So 😀 is stored as 😀 — two escapes for one visible character. That is not a bug; it is how the encoding works. When you escape 😀 in JavaScript or JSON style, you correctly get two tokens, and when you decode 😀 you must rejoin both halves to recover the single emoji. The common mistake is to iterate a string by index (str[i] or charCodeAt), which hands you one half of the pair and leaves you escaping a broken surrogate. Walking by code point with codePointAt and for...of keeps 😀 whole.

ES6 added a cleaner option: \u{...}. The braces allow one to six hex digits, so the whole emoji fits in one token — \u{1f600}. It reads better, but it is only valid in modern JavaScript (ES2015+), not in JSON. Use \uXXXX when you need JSON compatibility, and \u{...} when you are in modern JS and want readability for astral characters.

A full round-trip example

Take a deliberately mixed string: 中 😀 文. Encoding it in JavaScript/JSON style, escaping non-ASCII only, gives this:

中 😀 文

Notice the space and the plain text between escapes are left alone — only the non-ASCII characters changed. 中 became 中, the emoji became the surrogate pair 😀, and 文 became 文. In ES6 code-point style the same string is 中 \u{1f600} 文, with the emoji collapsed to a single token.

Now run it backward. Paste the escaped string into the decode side and you get 中 😀 文 again, exactly — same characters, same spacing, byte for byte. The decoder is forgiving: it will even accept a blob that mixes styles, like 中 😀 \u{6587}, and still return 中 😀 文, because 😀 is just the decimal HTML entity for the same emoji. That round-trip guarantee is the whole point. If a tool encodes a string and decoding it does not return the original, the escaper got the surrogate handling wrong.

I lean on this more than I expected to. The first time it earned its keep was a production incident where a downstream service logged display names as raw \u sequences. I had a wall of 王小明 with no idea who the user was. Pasting the block into the decoder turned it into 王小明 in under a second, and I could finally match the log line to a support ticket. No copying hex into a REPL, no guessing — just readable text.

Where each escape style belongs

The single most common real-world error is using the right escape in the wrong place. They are not interchangeable; each one is interpreted by a different parser.

  • JavaScript and JSON use \uXXXX (or \u{...} in modern JS only). The language parser reads the escape when it loads the source. This is the form to embed non-ASCII safely in code that has to travel through ASCII-only tooling.
  • HTML markup and email templates use entities: 😀 (decimal) or 😀 (hex). The browser renders the entity into the real character.
  • CSS uses \1f600 — a backslash, the hex digits, then a space to terminate it — typically inside a content property.

Paste an HTML entity into a JavaScript string and 😀 just sits there as five literal characters. Paste \u{1f600} into HTML and it shows up as raw text. Match the style to its home. If you frequently move escaped strings between languages, the broader String Escape Tool handles language-specific escaping for quotes, backslashes, and control characters alongside the Unicode work, which saves a round trip when a string has to be both Unicode-safe and quote-safe.

Encode-only-non-ASCII versus escape-everything

Most of the time you want to escape only the non-ASCII characters and leave plain English alone, so the output stays mostly readable — Hello 中 rather than a wall of escapes. That is the default for embedding a foreign-language label in otherwise English source. Occasionally you want to escape every character, including the ASCII, usually to hide a string from casual reading or to push it through a transport that mangles even basic punctuation. Both modes round-trip identically; the choice is purely about how much of the output stays human-readable. Uppercase versus lowercase hex (中 versus 中) is cosmetic — both decode to the same character — so pick whichever your codebase already uses.

Quick reference

To recap the rules that actually trip people up:

  • One UTF-16 code unit equals \u plus exactly four hex digits, zero-padded.
  • Characters above U+FFFF (most emoji) need a surrogate pair in \uXXXX, or a single \u{...} token in ES6.
  • Iterate by code point, never by index, or you will saw emoji in half.
  • \uXXXX for JSON and old JS, \u{...} for modern JS, &#...; for HTML, \1f600 for CSS.
  • Always verify by decoding back to the original — a correct escaper is reversible.

When you need to go the other way and inspect the raw bytes behind a character rather than its escape, the Text to Hex converter shows the underlying UTF-8 byte sequence, which pairs naturally with code-point escaping when you are debugging an encoding mismatch. And whenever you just need a clean text ⇄ escape round trip in any of these styles, the Unicode Escape Converter does it client-side with a shareable link.

Made by Toolora · Updated 2026-06-13