JSON Escape / Unescape
Convert text to an escaped form safe to embed in code strings, or revert it
JSON Escaping: Why Your JSON Contains All Those Backslashes
When escaping is required
A JSON string cannot contain raw special characters at will. A backslash, a double quote, and every control character (newline, tab, carriage return, backspace, and so on) must be written as an escape sequence:
| Escape | Meaning | Note |
|---|---|---|
\" | double quote | without it the string would end early |
\\ | backslash | must be escaped or it is read as an escape prefix |
\n | newline | a real newline in the text is an illegal control character |
\t | tab | common in pasted table data |
\r | carriage return | Windows newlines are \r\n |
\b \f | backspace, form feed | rare, but still must be escaped |
\uXXXX | any Unicode character | four hex digits; supplementary characters need two escapes |
\/ | slash | legal but not required, see below |
\/ is a historical leftover: the spec allows a slash to be escaped, but never requires it. The reason it exists is to stop JSON embedded directly into HTML from producing </script> and closing the script tag early. Modern serializers usually leave slashes alone, so when you see \/ it most likely comes from an older system or a specific serialization library.
Double serialization: the root of the backslash explosion
When one JSON document is placed as the string value inside another JSON document, it gets escaped twice, and to the eye it looks like a wall of backslashes:
| Layer | Content |
|---|---|
| raw object | {"a":1} |
| converted to a string and embedded (1 layer) | "{\"a\":1}" |
| embedded once more (2 layers) | "{\"a\":\"{\\\"a\\\":1}\"}" |
A practical way to count the layers is to remove one level of escaping at a time and see whether the result is again valid JSON. If removing one layer yields a string, and removing two yields an object, you are looking at double serialization. Each \\ you see stands for one serialization — count the backslashes and you have a rough estimate of how deeply it was nested.
The real consequence of double serialization: the receiver parses once, gets a string instead of an object, and every field access fails; or the deserialized field types no longer match the contract. The fix belongs at the end that produces the data (usually where strings were concatenated instead of serialized structurally), not in the consumer repeatedly decoding.
How this differs from two other kinds of escaping
| Approach | Target | Used in |
|---|---|---|
| JSON escaping | syntactic safety of a JSON string | inside a JSON value |
| URL percent-encoding | syntactic safety of a URL | query parameters, paths |
| HTML entity encoding | syntactic safety of HTML | HTML text and attributes |
These are not interchangeable. To put JSON into a URL parameter you must apply URL encoding when needed; to put JSON into an HTML page you must do HTML escaping (at minimum handling < > &), otherwise </script> will terminate the script block and <!-- will open a comment — a classic XSS entry point, and the reason modern code prefers carrying data in <script type="application/json"> rather than inlining it as a JavaScript variable.
How to use this tool
Two directions: turn text containing special characters into a form that can be safely embedded in JSON (escape), or turn sequences like \" \n \\ back into the original characters (unescape). When decoding, the tool strictly validates that each escape sequence is legal; a nonexistent escape such as \x is reported with its position rather than silently emitting wrong output.
FAQ
Why is there an extra layer of quotes after escaping?
Because a JSON string must be wrapped in quotes. That layer of quotes is exactly the marker that it can be embedded as a string. Remove the quotes and it is no longer a valid string.
What if unescaping fails?
Make sure the input is a complete JSON string literal including the surrounding quotes. If only the inner content is pasted, the tool tries to treat it as a string; if it still fails, the content itself is invalid.