Escape JSON strings, and get them back

Exactly three things, per RFC 8259 §7: the double quote, the backslash, and every character below U+0020. Everything else may appear literally, including the forward slash, the single quote, the ampersand and every emoji. Eight of the mandatory escapes have two-character forms — \" \\ \/ \b \f \n \r \t — and anything else that has to be escaped uses \u followed by four hex digits. A tool that escapes more than that is not making the JSON more valid, it is making it longer.

Because the HTML parser reads the page before the JavaScript parser does, and it is looking for </script>. If your data contains that sequence — in a stored HTML snippet, a code sample, a URL to a script file — the inline block ends there, mid-string, and everything after it becomes markup. The JSON was never wrong; it was in the wrong place unescaped. Escaping the angle brackets as \u003C and \u003E fixes it completely, because JSON reads them back as the same characters while the HTML parser sees no tag at all. That is what the “Safe inside <script>” switch does.

No, and JSON has never required it. The escape is legal — \/ is one of the eight two-character forms — but a bare / is equally legal, and most encoders leave it alone. The convention exists for the same reason as the one above: escaping the slash breaks up the </script> sequence, so some libraries do it by default, PHP's json_encode being the loudest example. If you are comparing output byte for byte against another system, that single difference is usually the cause.

As two escapes, because \u carries a UTF-16 code unit rather than a code point. 😀 is U+1F600, above the 16-bit range, so it is written as the surrogate pair 😀 — and any decoder that treats those two as separate characters produces mojibake instead. Below U+FFFF it is one escape: é is \u00E9 and 東 is \u6771. None of this is necessary in a UTF-8 document, where all three can be written literally; it only matters when the transport is ASCII-only.

The value was escaped twice, so the reader is seeing a backslash and an n rather than a newline. It happens when a string that is already JSON gets serialised again: the \n becomes \\n, and one round of parsing gives back the two literal characters. Paste it into the unescape direction here and you will get the real line break; if the result is itself a JSON document, this page indents it underneath, which is the fingerprint of a webhook that put its payload in a string field.

It is the Unicode line separator, and until 2019 it was a line terminator in JavaScript but a perfectly ordinary character in JSON. That mismatch meant a JSON document containing one was not always valid JavaScript, so pasting it into a script — or serving it as JSONP — produced an unterminated string literal from nowhere. ES2019 fixed the language and the problem is now confined to older engines, but the character still arrives in text pasted out of PDFs and word processors, so the safe mode here escapes it and its paragraph-separator sibling U+2029.

You can, and it is a legitimate thing to want — that is exactly what embedding a payload in a string field means. Paste the document into the escape direction and the output is one JSON string value holding all of it, quotes escaped and line breaks turned into \n. Just be clear that you are creating a second level of encoding: whoever reads that field has to parse twice, and forgetting the second parse is the most common way it goes wrong.