Unicode Escape Converter: UTF-16, Decimal and Hex

Choose a notation, then encode

Paste text directly; there is no file upload or batch mode. Conversion runs in the browser without sending the input in network requests.

Select Unicode escapes, decimal references or hex references, then click Encode text.
To read encoded text, click Decode tokens. It recognizes all three supported forms together; the format selection does not restrict decoding.
Copy the result. Input edits, format changes and errors clear the old output and disable copying. Clear empties both fields but keeps the format; paste a result back yourself for another operation.

Code units, code points and one-pass decoding

Why one character can need two escapes

Unicode mode writes every UTF-16 code unit as lowercase \u plus exactly four lowercase hex digits, without surrounding quotes. A becomes \u0041, Ā becomes \u0100 and an actual LF becomes \u000a. 😀 needs the pair \ud83d\ude00.

Numeric modes instead use complete code points: A你😀 becomes A你😀 or A你😀. Hex references have uppercase hex digits and no fixed width. Letters and spaces are encoded too.

The decoder reads fragments, not a program

It matches lowercase \u followed by four hex digits, decimal references ending in a semicolon, and hex references with &#x or &#X and a semicolon. Hex digits accept either case. Mixed \u0041你😀 becomes A你😀.

Replacement happens once: \u005cu0041 becomes literal \u0041, and &#65; becomes literal A. Newly formed sequences are not rescanned. This is not a full JavaScript or JSON parser; it does not evaluate code or render results as HTML.

The formats do not accept identical input

he 1.2.0 applies strict HTML checks only to numeric encoding and numeric-reference decoding. Unicode escape encoding and \u decoding accept NUL, U+0080 and U+FFFF, which numeric encoding rejects. All encoding modes reject lone surrogates; decoding rejects an output containing an unpaired surrogate.

The pair \uD83D\uDE00 decodes to 😀, but numeric surrogate references &#55357;&#56832; are rejected. So are ,  and &#1114112;.

Unicode escape questions

Why are some escape-like strings left unchanged?

Unrecognized forms stay literal, including \uZZZZ, \u{41}, \U0041, \n, &, &#xZZ; and &#65 without its semicolon. Plain 65 66 is not a list of character codes. Recognized numeric references can still fail strict validation.

Are spaces and line endings preserved exactly?

No trimming or Unicode normalization is applied, and empty input produces empty output. The textarea normalizes actual CRLF and CR to LF. At core level, CR can encode as , but strict numeric decoding rejects ; a universal round trip is not guaranteed.