Skip to the tool
DevToolBench

JSON Escape and Unescape

Turn text into a JSON string value, and back.

0 chars
Characters
0
Escapes
0
Lines in
0
Valid
—

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

What this tool does

JSON escape is the small transformation between a piece of text and a valid JSON string value: the quotes, the backslashes and the control characters get a \ in front of them, and everything else stays as it is. This page does it in both directions, and it does the reverse carefully — telling you exactly which sequence is invalid and where it starts, rather than failing with a position in a document you never wrote.

There is a third mode for the case that comes up more often than it should: taking an entire JSON document and turning it into a single string value, ready to be the payload field of another one.

How to use it

  1. Choose the direction: escape, unescape, or embed a whole document.
  2. Turn on quotes if you want a value you can paste straight into a file.
  3. Paste, then copy the result.

The rules, in full

JSON string escaping is one of the smallest specifications in wide use. Two characters must be escaped because they would otherwise end the string or start an escape: the double quote and the backslash. Every character below U+0020 must be escaped because the grammar forbids a raw control character inside a string — five of them have short names (\b, \f, \n, \r, \t) and the rest use \u followed by four hexadecimal digits. The forward slash may be escaped and never has to be. Nothing else is special.

That list is short enough to implement by hand, which is exactly the trap. Use JSON.stringify in any language that has it. It is the reference implementation of these rules, it handles the surrogate pairs, and it will not forget the vertical tab at two in the morning.

Where the double encoding comes from

The commonest reason people arrive at a page like this is a string that has been escaped twice: a value that should read C:\temp shows up as C:\\\\temp, or a newline appears as the four characters \ \ n — and no amount of staring makes it parse.

It is always the same shape. A service serialises a structure to JSON and logs the resulting text. A collector treats that log line as a plain string field and serialises again. Each pass escapes the escapes of the previous one, so backslashes double every time. Unescaping once per layer gets you back; the escape counter here goes to zero when there is nothing left to peel.

The cure is upstream: log the object and let the logger serialise once, or store the document as a nested object instead of a string. When it genuinely has to be a string — a queue message that carries an opaque payload — use the embed mode here, and reach for the JSON formatter first to confirm the document parses before you wrap it.

The forward slash and old JavaScript

\/ is the strangest thing in the specification: an escape that is allowed, changes nothing, and exists for a reason outside JSON. If a document is written into an HTML <script> block, the HTML parser looks for the closing tag before the JavaScript parser sees anything, so a string containing that sequence ends the script early. Escaping the slash splits it up while leaving the value identical.

Modern applications serve JSON from an endpoint rather than inlining it, and the problem disappears with the practice. Keep the option for the templates that still do it, and remember that a value also has to survive the HTML around it — the HTML entity encoder is the tool for that half.

Frequently asked questions

Why not just call JSON.stringify?

For escaping, you should — a runtime's own serialiser is faster, better tested and always available. This page exists for the other direction and for the times you have no runtime to hand: a string pasted out of a log, a Kubernetes annotation, a CI variable. And when an escape is malformed, JSON.parse says something like Unexpected token in JSON at position 41 and stops; the unescaper here names the offending sequence and where it starts.

Should I escape the forward slash as backslash-slash?

Not unless you are embedding JSON inside an HTML script element. JSON permits the escape and requires nothing, so both forms parse identically. The one case that matters is that the two characters that close a script element cannot appear inside it, and escaping the slash breaks the sequence up without changing the value. Anywhere else it is noise, which is why the option here is off by default.

Why is my log full of backslash-backslash-n?

Something escaped an already-escaped string. A service serialises an object to JSON, a second layer treats that text as a value and serialises again, and each pass doubles every backslash: a newline becomes \n, then \\n, then \\\\n. Unescape once per layer to peel it back — the escape count in the panel tells you when a pass actually changed something. The fix upstream is to log the object, not its JSON.

What does the non-ASCII option change?

It rewrites every character above the tilde as a \uXXXX escape, so the output is pure ASCII. JSON is defined over Unicode and a modern parser reading UTF-8 needs none of it. It still earns its place when the string has to cross something older or narrower than UTF-8 — a legacy driver, a config parser with a fixed encoding, an email header. An emoji becomes two escapes, because it is a surrogate pair.

Does anything I paste leave my browser?

No. Escaping and unescaping both run here in the page, which matters given that the strings people paste into a tool like this are usually production log lines.

Related tools

Updated