Unicode Escape Sequences Explained

Unicode escapes at a glance

Escape syntax is not the same as UTF-8 bytes. \u00E9 represents the code point U+00E9, while its UTF-8 bytes are C3 A9.

What is a Unicode escape sequence?

An escape sequence is source or data syntax that represents a Unicode character without writing the literal character directly. A parser interprets the escape, and the final in-memory string usually contains the character, not the backslash notation. Escapes are useful for invisible characters, controls, portability, generated data and formats where a literal character would be hard to read or type. Syntax depends on the language or format, and not every language supports every form. Many modern files can contain literal Unicode directly, so escaping is a tool, not a requirement.

Literal character: é
Unicode escape: \u00E9
Unicode code point: U+00E9
UTF-8 bytes: C3 A9

For the numeric model, read What Is a Unicode Code Point?, then try Unicode Escape Converter.

Escape sequences vs code points vs bytes

A parser converts escape syntax into a code point or string element. An encoder later converts the string into bytes. Writing UTF-8 byte values inside \u is incorrect: \uC3A9 is not the UTF-8 representation of é. Raw byte escapes and Unicode escapes may behave differently. Never copy UTF-8 bytes directly into \uXXXX syntax.

How \uXXXX works

\uXXXX uses exactly four hexadecimal digits in JavaScript and JSON. In those contexts it represents one UTF-16 code unit. BMP characters usually fit in one escape, while values above U+FFFF do not. Supplementary characters need a surrogate pair in formats limited to four-digit escapes. Other languages may use similar syntax with different rules.

A → U+0041 → \u0041
é → U+00E9 → \u00E9
Ж → U+0416 → \u0416
字 → U+5B57 → \u5B57

Leading zeroes are part of the fixed-width syntax. Hexadecimal digits may be written uppercase or lowercase, depending on style and format rules.

Characters above U+FFFF

The Basic Multilingual Plane ends at U+FFFF. Supplementary code points range from U+10000 to U+10FFFF, so four hexadecimal digits are not enough. Modern syntaxes may support full code-point escapes, while UTF-16-based \uXXXX syntax uses surrogate pairs.

😀
Code point: U+1F600

JavaScript code-point escape:
\u{1F600}

JavaScript/JSON surrogate-pair escapes:
\uD83D\uDE00

Python long Unicode escape:
\U0001F600

HTML hexadecimal reference:
😀

All of these can represent the same Unicode character in their valid contexts.

Surrogate-pair escapes explained

UTF-16 represents supplementary code points with two code units. Each code unit can be written as a \uXXXX escape. The first is a high surrogate and the second is a low surrogate. Together they represent one code point; isolated surrogate escapes are not valid Unicode scalar values.

😀 → U+1F600
High surrogate: D83D
Low surrogate: DE00
Escaped form: \uD83D\uDE00

For the underlying representation, read Code Points vs Code Units and UTF-8 vs UTF-16.

Interactive Unicode escape converter

This local converter shows text-to-escape forms, parses common escape syntaxes, reports malformed input and keeps URL percent encoding separate from Unicode escapes.

Unicode escapes in JavaScript

JavaScript supports four-digit escapes, modern code-point escapes and surrogate-pair forms. \u{...} requires modern JavaScript syntax. \uXXXX represents UTF-16 code units, so two surrogate escapes may combine into one code point. Escapes are interpreted in string literals and template literals unless raw handling is used.

const letter = "\u00E9";
const emoji = "\u{1F600}";
const sameEmoji = "\uD83D\uDE00";

console.log("\u00E9");        // é
console.log("\u{1F600}");     // 😀
console.log("\uD83D\uDE00");  // 😀

const literal = "\\u00E9";
console.log(literal); // \u00E9

The literal string contains six visible ASCII characters rather than é. String.raw preserves backslash sequences differently, which matters in templates and generated source.

Unicode escapes in JSON

JSON strings support \uXXXX. JSON does not support JavaScript's \u{...} syntax. Supplementary characters may be written as surrogate pairs, and literal Unicode characters are also allowed in JSON strings. JSON parsers interpret escapes while parsing, and double-escaped JSON can expose literal \uXXXX.

{
  "letter": "\u00E9",
  "emoji": "\uD83D\uDE00",
  "literal": "\\u00E9"
}

After parsing, letter is é, emoji is 😀, and literal contains the text \u00E9. Use JSON Escape and Unescape.

Unicode escapes in Python

Python string literals support \uXXXX for four-digit escapes and \UXXXXXXXX for eight-digit escapes. \xXX is a two-digit hexadecimal escape, not a general full-Unicode form. Raw strings change how backslashes are handled, and bytes literals have different semantics from text strings.

letter = "\u00E9"
emoji = "\U0001F600"

print(letter)
print(emoji)

literal = r"\u00E9"
print(literal)

import json

value = json.loads('"\\u00E9"')
print(value)

Python's unicode_escape codec is not a universal JSON or JavaScript escape parser. Avoid applying it broadly to arbitrary user text.

Unicode escapes in PHP

Modern PHP supports Unicode code-point escape syntax such as \u{1F600} in double-quoted strings. Single-quoted strings preserve most backslashes literally. JSON escape decoding should use json_decode(), and HTML entities should use HTML-specific functions. PHP strings remain byte sequences containing UTF-8 bytes when source files are UTF-8.

$letter = "\u{00E9}";
$emoji = "\u{1F600}";

echo $letter;
echo $emoji;

$literal = '\u{1F600}';

$value = json_decode(
    '"\uD83D\uDE00"',
    true,
    512,
    JSON_THROW_ON_ERROR
);

Do not use executable source parsing for user-provided escape strings. json_decode() follows JSON rules, not general PHP source syntax.

Unicode escapes in Java

Java source supports \uXXXX. Supplementary characters require surrogate pairs in ordinary string literals, and Java strings use UTF-16 code units. Literal backslashes require escaping.

String letter = "\u00E9";
String emoji = "\uD83D\uDE00";
String literal = "\\u00E9";

Java source-level Unicode escapes are processed early in source translation, so generated source, comments and examples should be handled carefully.

Unicode character references in HTML

HTML uses character references rather than backslash Unicode escapes. Decimal references use &#...;, hexadecimal references use &#x...;, and named entities exist for some characters.

<p>&#233;</p>
<p>&#xE9;</p>
<p>&#128512;</p>
<p>&#x1F600;</p>

Literal UTF-8 characters are usually clearer in modern HTML. JavaScript \uXXXX syntax is not HTML syntax. Use HTML Entity Encoder and Decoder.

Unicode escapes in CSS

CSS escapes use a backslash followed by one to six hexadecimal digits. A following whitespace may terminate the escape, and that terminator can be consumed. Escapes can appear in strings, identifiers and generated content, but CSS does not use JavaScript escape rules.

.icon::before {
    content: "\1F600";
}

.example::before {
    content: "\E9 ";
}

Unicode escapes in URLs

URLs use percent encoding of bytes, not \uXXXX as standard URL encoding. Unicode input is typically encoded as UTF-8 bytes and then percent encoded. é becomes UTF-8 bytes C3 A9, then %C3%A9. Writing %E9 may imply a legacy byte interpretation, and literal \u00E9 in a URL is usually backslash text unless an application interprets it specially. Use URL Encoder and Decoder.

Control escape sequences

Meaning depends on the language or format. JSON supports a defined subset. \b in a string is not a regular-expression word boundary, and double escaping is common when text passes through multiple parsers.

Literal escapes vs interpreted escapes

The rendered character é and the literal text \u00E9 are different strings. Literal escape text consists of the characters \, u, 0, 0, E and 9.

const interpreted = "\u00E9";
const literal = "\\u00E9";

console.log(interpreted); // é
console.log(literal);     // \u00E9

Whether an escape is interpreted depends on the parser, number of escape layers, string literal rules, JSON serialization, template processing, database storage and user interface display.

What is double escaping?

Double escaping happens when a character is escaped once and the backslash is escaped again for another format. After one parsing layer, literal escape text remains. After a second deliberate parser, the character may appear.

{
  "value": "\\u00E9"
}

After JSON parsing, the value is literal \u00E9. A second Unicode-escape parser would produce é, but that should happen only when the application contract requires it.

Escapes in APIs and databases

APIs may transport literal Unicode or escaped JSON. JSON serializers usually handle escaping automatically, so application code should not manually escape JSON strings before serialization. Manual pre-escaping can cause double escaping. Databases generally store the resulting string, not source-language escape syntax. A stored \u00E9 may be literal text if it was never parsed, while logs may show escaped representations even when the in-memory value is correct.

Unicode string
→ JSON serializer
→ UTF-8 bytes
→ transport
→ JSON parser
→ Unicode string

Inspect both the serialized payload and the parsed application value.

Unicode escapes and normalization

Escapes represent code points. Different escape sequences can represent different normalization forms. NFC é may be written as \u00E9, while NFD é may be written as \u0065\u0301. Both may display identically. Escape conversion does not automatically normalize, and normalization may change the escape sequence after conversion. Read Unicode Normalization Explained, NFC vs NFD and use Unicode Normalizer.

Unicode escapes and grapheme clusters

One grapheme cluster may require several escaped code points. Combining sequences, emoji ZWJ sequences, modifiers and variation selectors can all be represented by multiple escapes. Escaping each code point does not break the sequence by itself, but removing or reordering escapes can change rendering.

é
\u0065\u0301

♥️
\u2665\uFE0F

👨‍👩‍👧‍👦
\u{1F468}\u{200D}\u{1F469}\u{200D}\u{1F467}\u{200D}\u{1F466}

Read What Is a Grapheme Cluster? and inspect sequences with Unicode Sequence Analyzer.

Safe escape parsing

1. Identify the syntax family.
2. Do not mix JSON, JavaScript, Python and HTML parsers.
3. Reject malformed escapes.
4. Reject code points above U+10FFFF.
5. Reject isolated surrogates in code-point contexts.
6. Handle valid surrogate pairs.
7. Limit input size.
8. Never use executable language evaluation.
9. Preserve original text.
10. Report ambiguous or literal backslashes.
11. Avoid repeated unescaping.
12. Test round trips.

Parse data with the parser for its actual format.

Common Unicode escape mistakes

Treating UTF-8 bytes as \u values

C3 A9 is UTF-8 bytes; \u00E9 is the escape for U+00E9.

Using one \uXXXX for a supplementary character

Use surrogate pairs or a supported code-point escape.

Using JavaScript \u{...} inside JSON

JSON does not support that syntax.

Forgetting to escape the backslash

\\u00E9 and \u00E9 produce different values.

Double escaping JSON

Let the serializer handle strings.

Repeatedly unescaping text

This can corrupt legitimate backslashes.

Using executable source parsing to decode escapes

Use a parser for the actual format.

Confusing HTML entities with Unicode escapes

Different parsers and syntax are involved.

Confusing URL percent encoding with \uXXXX

URLs encode bytes.

Treating \xXX as full Unicode

Its meaning is language-specific and limited.

Ignoring isolated surrogates

They are not valid Unicode scalar values.

Assuming escaped text is normalized

Escape representation and normalization are separate.

Converting text to Unicode escapes in JavaScript

function toUnicodeCodePointEscapes(text) {
    return [...text]
        .map(character => {
            const codePoint = character.codePointAt(0);
            return `\\u{${codePoint
                .toString(16)
                .toUpperCase()}}`;
        })
        .join("");
}

const json = JSON.stringify("Aé😀");

JSON.stringify() may leave many Unicode characters literal, which is valid JSON. Do not assume it always emits \uXXXX. A custom escape function should be used only when the output format requires it, and spread iteration handles code points, not grapheme clusters.

Converting text to Unicode escapes in Python

def to_code_point_escapes(text: str) -> str:
    parts = []

    for character in text:
        code_point = ord(character)

        if code_point <= 0xFFFF:
            parts.append(f"\\u{code_point:04X}")
        else:
            parts.append(f"\\U{code_point:08X}")

    return "".join(parts)

import json

escaped = json.dumps(
    "Aé😀",
    ensure_ascii=True,
)

ensure_ascii=True escapes non-ASCII characters. Supplementary characters may be represented according to JSON encoder behavior. unicode_escape output is Python-specific and not necessarily JSON-compatible.

Converting text to Unicode escapes in PHP

function toUnicodeCodePointEscapes(string $text): string
{
    $characters = mb_str_split($text, 1, "UTF-8");
    $parts = [];

    foreach ($characters as $character) {
        $codePoint = IntlChar::ord($character);
        $parts[] = "\\u{" . strtoupper(dechex($codePoint)) . "}";
    }

    return implode("", $parts);
}

$json = json_encode("Aé😀", JSON_THROW_ON_ERROR);

JSON_UNESCAPED_UNICODE controls whether many Unicode characters remain literal. Both escaped and literal Unicode can be valid JSON. mbstring and intl may be required, and untrusted input should not be concatenated into executable PHP source.

Practical debugging workflow

1. Identify the actual format.
2. Preserve the original input.
3. Determine whether backslashes are literal.
4. Count parsing layers.
5. Inspect code points.
6. Validate escape syntax.
7. Check surrogate pairs.
8. Decode with the correct parser.
9. Compare parsed output.
10. Check normalization.
11. Re-encode or serialize once.
12. Add round-trip tests.

Use Unicode Escape Converter, JSON Escape and Unescape, JavaScript Escape and Unescape, Unicode Character Inspector and Text to Unicode Code Points.

Try these UnicodeNow tools

These tools convert escapes, inspect code points and compare parsed output across common web and code formats.

Frequently asked questions

References

• The Unicode Standard
• Unicode glossary
• ECMAScript language specification: string literals
• JSON specification
• RFC 8259: The JavaScript Object Notation Data Interchange Format
• Python lexical analysis: string and bytes literals
• PHP manual: string syntax
• Java Language Specification: Unicode escapes
• HTML character references
• CSS Syntax Module Level 3: escaping
• WHATWG URL Standard
• MDN: JavaScript lexical grammar string literals
• Python documentation: json
• PHP manual: json_encode
• PHP manual: json_decode