JSON Escape Tool

Storing a JSON document as a string inside another one is common and slightly unfortunate. It happens when a schema has an opaque metadata or payload field, when a queue message wraps a body it does not want to interpret, or when a database column holds serialised data. It works, but it costs you: the inner document cannot be queried or validated by anything that understands the outer one, and every layer of nesting adds another round of escaping. If you control the schema, a real nested object is almost always better than a stringified one.

JSON escaping makes text safe inside a JSON string, and nothing else. It is not HTML escaping, so an escaped JSON string dropped into a page can still carry a script tag; it is not SQL escaping, so it does not make a value safe to concatenate into a query; and it is not shell escaping. Each context has its own rules, and the reliable approach is to escape at the point of use, with the mechanism that context provides — parameterised queries, a templating engine that escapes by default — rather than hoping one round of escaping covers everything.

Whenever a JSON document has to live inside a string. The common cases are a JSON payload stored as a string field within another JSON document, a request body embedded in a test fixture or a shell script, JSON pasted into a database column or an environment variable, and JSON assigned to a string literal in source code. In all of them the inner quotes must be escaped, because otherwise the first one terminates the surrounding string and everything after it is a syntax error.

Double quotes and backslashes, because they would otherwise end the string or start an unintended escape, plus the control characters that cannot appear literally in a JSON string — newline becomes \n, carriage return \r, tab \t, along with backspace and form feed. Note the order matters: backslashes have to be escaped before quotes, or you end up double-escaping. Getting that wrong by hand is exactly why this is worth using a tool for.

Because each layer of nesting doubles them. A quote inside a string is \", and if that string is itself inside another string it becomes \\\", and a third level doubles again. This is the classic problem with JSON stored inside JSON stored inside a shell command, and it is genuinely difficult to get right manually. If you find yourself three levels deep, it is usually a sign the data should be passed as a file or a separate field rather than embedded.

It is the same idea as calling JSON.stringify on a string value — you get the escaped representation. The distinction worth keeping clear is that JSON.stringify on an object produces JSON, while stringify on a string produces an escaped, quoted string. This tool does the latter to whatever you paste, treating your input as text to be made safe for embedding rather than as data to be serialised.

No. Every tool runs in your browser as JavaScript — your data is never uploaded, never logged, and never sent to a server. You can confirm it by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and seeing that everything still functions. That matters for JSON in particular, because API responses routinely contain personal data, tokens, and internal identifiers.