JSON Unescape
Decode escaped JSON strings back to plain text — \n becomes a real line break, \" a real quote, \u00e9 an é.
Where escaped strings come from
Log pipelines, message queues and databases love wrapping things in strings. A stack trace stored in a JSON field arrives as one line full of \n; an API that returns JSON inside JSON gives you {\"nested\":true}; a copied cURL response is peppered with \u00fc. Unescaping turns that back into text you can read: real line breaks, real quotes, real unicode characters.
The double-escaped JSON problem
The classic case: a JSON document was serialized as a string value inside another JSON document — sometimes twice. You recognize it by \\\" and armies of backslashes. Because each unescape pass removes exactly one level, the fix is mechanical: paste, press Unescape, and repeat until it looks like JSON. Then paste the result into the JSON Formatter to validate and pretty-print it.
What the decoder accepts
The input is interpreted as the body of a JSON string (surrounding quotes optional — the tool handles both). All escapes from RFC 8259 are decoded: \", \\, \/, \b, \f, \n, \r, \t and \uXXXX including surrogate pairs for emoji. Invalid escape sequences are reported with their exact position rather than silently mangled — this is a decoder, not a guesser.
Frequently asked questions
Do I paste the string with or without the surrounding quotes?
Either works. If the input starts and ends with a double quote, the tool treats them as the string delimiters and decodes what is between them; otherwise it decodes the input as the raw string body.
Why is my output still full of backslashes?
It was escaped more than once — JSON inside JSON inside JSON is common in logging stacks. Each Unescape pass removes exactly one level; run it again until the text is clean.
Can it decode \uXXXX unicode escapes and emoji?
Yes. \u00e9 becomes é, and surrogate pairs like \ud83d\ude00 combine into the actual emoji 😀. The decoding follows RFC 8259 exactly.
What happens with an invalid escape like \x?
You get an error with the exact position instead of corrupted output. \x is not a legal JSON escape — if the source produced it, the string was never valid JSON in the first place.