Escape and unescape text for JSON.

What gets escaped

JSON strings are double-quoted, so a handful of characters cannot appear literally inside them. Escaping replaces each one with a backslash sequence.

Where you need this

• Embedding a multi-line SQL query or template as a single JSON config value.
• Putting a Windows path such as C:\logs\app.log into a payload — every backslash has to double.
• Building a request body by hand in a shell script or an HTTP client.
• Reading a log line where an entire response was escaped into one field.

Escaping is not encoding

JSON escaping, URL encoding and HTML entity encoding solve different problems and are not interchangeable. A value going into a query string needs encodeURIComponent; a value rendered into markup needs HTML escaping; a value going inside a JSON string needs what this tool does. Applying the wrong one produces text that looks almost right and breaks at the worst moment.

Escaping in your own code

// JavaScript — escape, then trim the outer quotes
JSON.stringify(text).slice(1, -1)

# Python
json.dumps(text)[1:-1]

// Java
JSONObject.quote(text);        // keeps the quotes

// C#
JsonEncodedText.Encode(text);

Every one of these delegates to the language's own JSON serializer rather than doing a hand-rolled find-and-replace. That matters: a manual replace('"', '\\"') misses control characters, mishandles backslashes that were already escaped, and produces output that parses in testing and fails on the first tab character in production.

Unescaping safely

In the other direction, resist the temptation to reach for eval orast.literal_eval on untrusted text. Wrapping the body in quotes and running it through the JSON parser — what this page does — is both safer and stricter. If the input is a full JSON document rather than a bare string, the string to JSON converterhandles it and formats the result at the same time.

Escaping is not encryption, or sanitisation

A JSON-escaped string is trivially reversible and offers no protection whatsoever. More importantly, escaping for JSON does nothing to make a value safe in any other context. Text that is correctly escaped as a JSON string can still be a SQL injection when concatenated into a query, still be an XSS payload when written into a page, and still be a command injection when passed to a shell. Each destination needs its own escaping, applied at the point of use.

The one rule that prevents nearly all of these mistakes: escape at the boundary, once, using the mechanism belonging to that boundary — parameterised queries for SQL, the framework's templating for HTML, an argument array rather than a string for subprocesses. Escaping early and carrying the escaped form around is how values end up double-escaped, with \\n appearing literally in your output.

Double escaping, and how to spot it

If you see \\\\n or \\\\" in a payload, a value was escaped twice — usually because an already-serialized string was handed to a serializer again. Run it throughUnescape once and check: if the result still contains backslash sequences, peel another layer. The string to JSON converter does this automatically when the result is a full document.