Unicode escapes

Above U+FFFF there are two right answers

This is what separates a correct converter from a broken one.

Every character up to U+FFFF is one \uXXXX escape and there is nothing to decide. Above that — most emoji, and mathematical letters like 𝕏 (U+1D54F) — JavaScript stores the character as a surrogate pair, two 16-bit halves that mean nothing individually.

So 𝕏 can be written two ways:

• \u{1D54F} — one escape for one character. Modern JavaScript, Rust, Swift.
• \uD835\uDD4F — the UTF-16 pair. Older JavaScript, Java, and most JSON tooling.

Both are correct in their own context. The default here is the first, because a pair of lone surrogates pasted somewhere that is not UTF-16 is the thing that breaks. Switch styles when your target needs the other.

\U0001D54F is the Python and C form, and \1d54f — hex followed by a terminating space — is the CSS one.

The bug this exists to avoid

A converter that walks the string by index rather than by character splits surrogate pairs in half. The output looks plausible and decodes to nothing usable, and it fails only on emoji, which is exactly the input people test last.

Everything here iterates by code point, so pairs stay whole.

Emoji are often several characters

👨‍👩‍👧 is not one character. It is five: three people joined by two zero-width joiners (\u200D). Escaping it produces all five, and dropping the joiners silently turns one family into three separate people.

Flags work the same way — 🇹🇼 is two regional indicator symbols — and skin-tone variants add a modifier on top.

Going back

The decoder accepts everything anyone is likely to paste: \uXXXX, \u{...}, \UXXXXXXXX, \xNN, %uXXXX and a bare U+XXXX. Consecutive surrogate halves are recombined into the character they were meant to spell.

Text that is not an escape is left alone, so a Windows path like C:\Users\me survives intact rather than being mangled by the \U.

Nothing is uploaded

Converted in this page.