English text is nearly always the "boring" case for Unicode escaping — but the syntax itself is everywhere in JavaScript source code, not just JSON: \u0041 works directly inside a JS string literal, which is why escape sequences show up constantly in minified or obfuscated code even when the underlying text is plain ASCII.
Two different escape syntaxes in JavaScript
JSON only supports the four-hex-digit form, \uXXXX. JavaScript string literals support that too, but ES6 added a second form, \u{XXXXX}, which can represent any Unicode code point — including ones outside the Basic Multilingual Plane — in a single escape, without needing a surrogate pair. "\u{1F600}" and "\ud83d\ude00" produce the exact same emoji character; the first is just easier to read and edit.
Why this matters for code, not just content
Because JavaScript identifiers can also contain escaped Unicode (\u0061 is a valid stand-in for the letter "a" in a variable name), escape sequences are a real vector for obfuscated or malicious code — a script can hide a call to a suspicious function behind a wall of escapes that looks like gibberish but executes identically to the plain-text version.
When you need this
- Reading, in plain language, what text is hiding behind escape sequences in a JSON API response or minified script.
- Preparing a string for an environment that doesn't accept non-ASCII characters.
- Diagnosing encoding issues when working with external data.
A common mistake: a broken surrogate pair
If you truncate a string or process escape codes one at a time without accounting for surrogate pairs, the first code of a pair can end up separated from the second. The result is an invalid orphan code unit — a lone \ud83d with no matching \ude00 — which most parsers reject with an error or render as the replacement character "�".