Unicode Escape and Unescape Converter
Decode \uXXXX sequences into readable characters, or encode accents, CJK, Cyrillic and emoji so a payload survives an ASCII-only pipeline.
To dodge encoding problems, plenty of systems write every non-ASCII character as a \uXXXX escape. The result is an API response that is a wall of \uXXXX escapes with nothing readable in it, impossible to scan and awkward to compare. This tool decodes those sequences back into characters, and works in the other direction too: encoding text so the payload is pure ASCII and can pass through a channel that would otherwise mangle it.
The conversion is plain text replacement and does not require valid JSON, so fragments, half-finished documents and syntactically broken text are all accepted. Processing happens in the browser, which means pasted resource files and payloads with non-ASCII content are not uploaded or cached, and the page keeps working with no network connection.
Which escape forms are recognized
The decoder matches a backslash, the letter u, and exactly four hexadecimal digits. Forms outside that shape are left untouched: the ES6 code point syntax with braces, for example \u{1F680}, is not recognized and will pass through unchanged. Decoding proceeds per UTF-16 code unit, and characters outside the Basic Multilingual Plane — anything above U+FFFF — are stored in JSON as a surrogate pair such as \uD83D\uDE80. Decoding renders them as the single character they represent, and there is no need to merge the pair by hand beforehand.
What the encoder covers, and how it behaves
The encoder is deliberately not selective about scripts. Its rule is to escape every character whose code point is above 0x7F, which means accented Latin letters, curly quotes, full-width punctuation, Greek, Cyrillic, CJK and Japanese kana are all converted, while ASCII letters, digits and half-width symbols stay as they are. The benefit is that the output can be dropped into any channel that only tolerates ASCII without further negotiation. Mixed content is handled in one pass, so there is no need to split a document into segments, and both directions are idempotent — running the same direction twice does not double-encode what was already converted.
The size cost, and when to use it
Escaping inflates text noticeably. A CJK character occupies 3 bytes in UTF-8 but 6 ASCII bytes as \uXXXX, and an emoji occupies 4 bytes in UTF-8 but 12 bytes as a surrogate pair of escapes — roughly double, or worse. Escape only when the receiving system genuinely requires ASCII; doing it because the escaped form looks safer costs real bandwidth and buys nothing. In the other direction, a document full of \uXXXX becomes far easier to search and diff once decoded. One caveat: the conversion is purely textual and does not track whether a sequence sits inside a string, so escapes appearing in keys, comments or documentation are converted as well.
Frequently asked questions
- The decoded text is still garbled — what went wrong?
- That means the original data was already damaged in transit; decoding cannot repair it. The usual cause is a mismatch between the writing and reading side: bytes written as UTF-8 but decoded as Latin-1 or Windows-1252, or a response sent without a charset declaration. Escape sequences contain only ASCII, which is the least error-prone representation there is. Fix the character set on the reading side, then convert.
- Why did an emoji turn into two \u escapes?
- Its code point is above U+FFFF, so UTF-16 represents it as a surrogate pair, and \uD83D\uDE80 is the correct, expected form. Such a pair is legal inside a JSON string, renders as one character after decoding, and gives identical results in every parser. There is no need to merge the two halves by hand.
- Does converting change the meaning of my JSON?
- No. Inside a JSON string, \u00e9 and the literal character denote the same code point and parse to exactly the same value; only size and readability differ. Because the conversion is a text-level operation, though, it does not know where string boundaries are — escapes in keys or comments are converted too, so check the scope when running it on invalid or loosely structured text.
- Can I convert an entire file at once?
- Yes. Select and paste the whole content and convert; the tool operates on everything in the editor. There is no line or size limit, and the only practical constraint is browser memory and editor rendering speed — text in the low megabytes is usually handled without trouble.