Unicode Escape Converter

What this tool is used for

• Putting a character into a JSON string or a properties file whose tooling cannot carry it directly.
• Making an invisible or ambiguous character visible in a diff by escaping it explicitly.
• Reading escaped output from a logger or a serialiser back into the characters it represents.
• Writing a source file that must stay pure ASCII while still containing non-ASCII strings.
• Checking whether a string contains a lone surrogate before it reaches something that rejects them.

Frequently Asked Questions

Why are there different escape formats?

Each language chose its own: \uXXXX in JavaScript, Java and JSON; \u{XXXXX} for astral characters in modern JavaScript; \U0001F600 in Python and C; 😀 in HTML; and %F0%9F%98%80 in URLs. They encode the same character differently.

Why do emoji need two \u escapes?

Because \uXXXX addresses only 16 bits, and characters above U+FFFF must be written as a surrogate PAIR — \uD83D\uDE00 for the grinning face. Splitting that pair produces an invalid lone surrogate, which is a common source of corruption.

What is a lone surrogate?

Half of a surrogate pair standing on its own. It is valid in JavaScript strings but not valid Unicode, so it cannot be encoded to UTF-8 — which is why JSON.stringify can produce output that some parsers reject.

When should I escape rather than use the character directly?

When the transport is unreliable — source files with uncertain encoding, config read by legacy tools, or protocols that mangle high bytes. Modern UTF-8 pipelines are better served by the literal character, which is readable.

Do escapes affect string length?

Not after parsing — \u00e9 is one character once decoded. But the escaped SOURCE is six characters, which is why counting length before parsing gives the wrong answer.

How do I escape a character above the basic plane?

Either as a surrogate pair of two `\uXXXX` escapes, or with the `\u{...}` form where the language supports it. JSON has only the pair form, which is why an emoji in JSON is always two escapes.

Does escaping change how a string compares?

No — an escape is resolved at parse time, so the resulting string is identical to one written with the literal character. What it does change is the source file's encoding requirements, which is the usual reason to use it.

Common errors and gotchas

• Expecting one escape per character. Anything above the basic plane needs a surrogate pair, so emoji take two escapes.
• Assuming escaping changes the string. It changes the source representation only, and comparisons on the decoded value are unaffected.
• Producing a lone surrogate by splitting a pair, which is not a valid character and gets rejected or replaced downstream.
• Mixing escape syntaxes between languages, where the braced and fixed-width four-digit forms are not interchangeable.
• Escaping characters that never needed it, which makes the string unreadable without making it any safer.