JSON

JSON Unescape

Decode a backslash-escaped JSON string back into readable text, including \uXXXX sequences.

Private by design — your data never leaves your device.
✓ Free forever✓ No sign-up✓ No ads✓ Works offline once loaded

JSON Unescape

Decode a backslash-escaped JSON string back into readable text, including \uXXXX sequences.

Input

Escaped string

Nothing is uploaded.

Output

Plain text

Your result appears herePaste on the left and select “Unescape”

You find it in a log aggregator, an error field or a database column: a wall of {\"level\":\"error\",\"detail\":\"…\\n…\"} that is technically the information you need and practically unreadable. It is a JSON document that was serialised into a string and embedded inside another JSON document, and every quote in it now wears a backslash.

This tool reverses the encoding. Escape sequences become the characters they stand for, \n becomes a real line break, and \uXXXX becomes the character it names. Paste the value with its surrounding double quotes if it has them — that is the unambiguous form, and the one to use whenever the text contains escaped quotes of its own. A plain fragment with no outer quotes works too.

How it works

How to use the json unescape

  1. 1

    Paste the escaped string

    Copy the value out of your log line, database cell or error message exactly as you found it, keeping the surrounding double quotes if they are there.

  2. 2

    Unescape

    Every escape sequence is decoded in a single pass using the browser's own JSON parser, so the result matches precisely what a real consumer of that string would see.

  3. 3

    Format the result if it is a document

    If what comes out is itself JSON — which it very often is — send it to the JSON Formatter to get an indented, readable version.

What gets decoded

All eight of the escape sequences the JSON grammar defines, plus unicode escapes:

  • \", \\ and \/ become ", \ and /.
  • \n, \r and \t become a real newline, carriage return and tab.
  • \b and \f become backspace and form feed.
  • \uXXXX becomes the character at that code point — \u00e9 becomes é, \u2713 becomes . Surrogate pairs such as \ud83d\ude80 combine correctly into a single emoji.

A backslash followed by anything else is not a valid JSON escape and will be reported as an error rather than quietly passed through, which is usually a sign the text was mangled somewhere upstream — a Windows path whose backslashes were never escaped in the first place is the classic case.

Where these strings come from

Understanding the source usually tells you what to do with the result. Four situations produce almost all of the escaped JSON you will meet:

  • Structured logs. An application logs an object; the logging library serialises it into a message field that is itself a string inside the log envelope. The log viewer then shows you the envelope, escapes and all.
  • Nested API payloads. Webhooks and message queues frequently carry a JSON body inside a string field so that the outer envelope can stay schema-stable while the inner payload varies. Stripe, GitHub and most event buses do some version of this.
  • Database columns. A JSON document stored in a TEXT column and pulled out by a client that quoted it again on the way to your screen.
  • Error messages. A parser rejects a document and quotes the offending input back at you — already escaped, because the error itself is being serialised as JSON.

In every case the escaped string is a payload, not a display format. Unescape it, and if what emerges is a JSON document, format it. Two clicks turn an unreadable log line into something you can actually debug.

Double-escaped strings and how to spot them

When a payload passes through several systems, each one may escape it again. The tell is a run of backslashes: \\" means the string contains a literal backslash followed by a quote, which is what you get when an already-escaped document was escaped a second time. \\\\ in the source means two escaping layers deep.

The fix is simply to run the tool repeatedly. Each pass peels off exactly one layer, and you stop when the output stops changing and reads like plain text. Doing it in one greedy pass would be wrong — it could not tell an intentional literal \n in the text from a newline that had been escaped twice.

This layered escaping is endemic in log pipelines, where an application logs a JSON string, the logging library wraps that in its own JSON envelope, and the shipper wraps that for transport. Three layers is common.

Common questions

JSON Unescape FAQ

Should I include the surrounding quotes?

Include them when the value has them — a string whose own quotes are escaped, such as an embedded JSON document, needs the outer pair to be read unambiguously. A bare fragment with no escaped quotes in it can be pasted on its own and the tool will wrap it for you.

Why is my output still full of backslashes?

The string was escaped more than once as it moved between systems. Run the tool again on the output — each pass removes exactly one layer. Stop when the result stops changing.

It says the string is invalid. What went wrong?

Almost always a stray backslash that is not part of a valid escape sequence, such as a raw Windows path like C:\reports that was embedded without escaping, or a truncated \u escape missing some of its four hex digits. Fix or remove the offending backslash and retry.

Does it decode HTML entities or URL encoding?

No. This handles JSON backslash escapes only. & is an HTML entity and %20 is percent-encoding — different layers, different tools, and decoding them here would corrupt text that legitimately contains those sequences.

What happens to <code>\uXXXX</code> escapes and emoji?

They are decoded to the characters they represent, and surrogate pairs are combined correctly, so \ud83d\ude80 comes back as a single rocket rather than two broken halves. Non-ASCII text that was escaped by an ASCII-only serialiser becomes readable again in one pass.

Is the text I paste sent anywhere?

No. Decoding runs in a Web Worker in your browser. This matters more here than almost anywhere else on the site, because escaped strings are usually copied out of production logs and carry request bodies, user identifiers and occasionally credentials.