JSON Escape
Turn arbitrary text — SQL, HTML, logs, whole documents — into a safely escaped JSON string value.
Plain text
Escaped for JSON
Sooner or later you need to put text that was never designed for JSON inside JSON: a multi-line SQL query into a test fixture, an HTML template into a config value, a stack trace into a log field, a Windows file path with its backslashes into an API request. Paste it raw and the document breaks on the first quote or newline, usually with an error that points at a line nowhere near the real problem.
This tool converts the text into a valid JSON string body — quotes and backslashes escaped, real line breaks turned into \n, tabs into \t, control characters into \u sequences. The output has no surrounding quotes, so you can drop it straight between a pair you have already typed. Escaping uses the browser's own JSON.stringify, so the rules match exactly what any JSON parser will expect on the way back out.
How to use the json escape
- 1
Paste the raw text
Anything at all: a query, a code snippet, an email body, a certificate, a whole XML document. Line breaks and tabs are preserved as escapes rather than lost.
- 2
Escape
The output is the escaped string body, without the enclosing double quotes — copy-paste ready for a position inside a JSON document where you have already written them.
- 3
Paste it between quotes
Drop the result into your JSON as
"…", then run the whole document through the JSON Validator to confirm it parses.
Exactly what gets escaped
JSON strings have a short and rigid set of rules. Two characters must always be escaped, and every control character below U+0020 must be escaped somehow:
"becomes\"— the double quote, which would otherwise terminate the string.\becomes\\— the backslash, which starts every other escape.- Newline, carriage return and tab become
\n,\rand\t. Backspace and form feed become\band\f. - Any other control character —
NUL,ESC, and the rest of the C0 range — becomes a six-character\u00XXescape.
Two things are deliberately not escaped. The forward slash may optionally be written as \/, but it does not need to be and this tool leaves it alone. And non-ASCII characters — accented letters, CJK text, emoji — are left as themselves, because JSON documents are UTF-8 and é is a perfectly legal string character. Escaping them to \u00e9 is only necessary if something downstream is stuck in an ASCII-only pipeline.
Escaping is not encoding, and it is not sanitising
Two adjacent mistakes are worth naming. First, JSON escaping is not URL encoding. %20 and + have no special meaning in JSON, and a JSON escape means nothing in a query string. If a value needs to survive both, apply each transformation at the layer that requires it, in the right order.
Second, escaping does not make untrusted content safe to render. It makes it safe to transport inside a JSON document. A script tag escaped for JSON is still a script tag when the receiving page writes it into the DOM. Output escaping for HTML is a separate step performed at render time by the consumer.
On the other hand, escaping is the correct and complete defence against JSON injection — the bug where user input containing a quote breaks out of its string and adds fields to the document. Building JSON by string concatenation without escaping is the JSON equivalent of SQL injection, and the real fix is to serialise a data structure rather than glue text together.
The inputs that catch people out
Windows paths. C:\reports\2024\q4.csv is the classic. Every backslash doubles, giving C:\\reports\\2024\\q4.csv. Pasted unescaped, \r silently becomes a carriage return and \2 is an outright syntax error — a bug that looks like data corruption rather than a quoting mistake.
Regular expressions. A pattern is mostly backslashes, so escaping roughly doubles its length and makes it hard to read. This is genuinely unavoidable in JSON, and it is one of the better arguments for keeping regex patterns in a YAML or TOML config instead.
PEM keys and certificates. Multi-line blocks that must become a single string with \n between the lines. This is exactly the format most cloud providers expect for a private key in an environment variable, and doing it by hand is where the mistakes happen.
Whole documents. An XML payload, an HTML email body or a SQL migration going into a string field. All of them are full of quotes and line breaks and none of them can be pasted raw.
In each case the safe workflow is the same: escape here, paste between quotes, then run the finished document through the JSON Validator before you ship it. If a value came from a program rather than your clipboard, use that language's serialiser instead — every one of them escapes correctly for free.
JSON Escape FAQ
Why does the output have no surrounding quotes?
Because the usual reason to escape a string is to paste it into a JSON document at a position where the quotes are already there. Add them yourself if you need a complete JSON string literal.
Are accented characters and emoji escaped?
No. JSON is UTF-8 and those characters are legal in a string as-is, so they are left readable. Only the two structural characters and the control characters are escaped. If a downstream system demands pure ASCII, escape them separately.
What happens to my line breaks?
They are converted to \n (and \r\n to \r\n escapes), so the text becomes a single JSON string that still contains the line breaks when parsed. A literal newline inside a JSON string is a syntax error, which is why this conversion is required rather than cosmetic.
Can I escape a whole JSON document to nest it in another one?
Yes, and that is a common use — an API that carries a JSON payload inside a string field. Paste the inner document here and use the result as the string value. The nesting is legal but hard to read, so unescape it before debugging it.