Escape text into a JSON string literal, or unescape one back — control characters, quotes and unicode handled exactly as the JSON grammar requires, and invalid escape sequences reported with their position instead of being quietly passed through. Free, no sign-up — runs locally in your browser.
Why escaping JSON strings by hand goes wrong
Sooner or later every developer has to embed a piece of text
inside a JSON string: a Windows path with its backslashes, a
log line with quotes, a paragraph with real newlines, an
error message copied out of a stack trace. Done by hand it
fails in the usual two ways — a backslash you forgot doubles
as an escape and eats the next character, or a raw newline
lands inside the literal and the document stops parsing
three services downstream. The reverse trip is worse:
reading an escaped string out of a file and decoding it
mentally is slow, and the tools that “helpfully” accept
every escape ever invented teach spellings real parsers
reject. This tool does both directions by the grammar —
exactly the escapes JSON defines, strict errors with
positions for the ones it doesn't.
How to use this tool
- Paste the text — raw text for escaping, or an escaped string (with or without its surrounding quotes) for unescaping.
- For escaping, leave both options off unless a downstream pipeline needs them; they exist for HTML embedding and legacy toolchains, not for JSON itself.
- Press Escape → or ← Unescape.
- On unescape, an error means the input is not a valid JSON string: read the position, it points at the offending escape or the unclosed quote. A note about lone surrogates means the string decoded but contains a character UTF-8 cannot carry.
- Copy or download the result.
The rules it follows
Escaping always writes the complete
literal, quotes included. " and \
are escaped unconditionally; backspace, tab, newline, form
feed and carriage return use their short forms
(\b \t \n \f \r); the remaining control
characters below U+0020 become \u00XX.
Everything else — including / and all
non-ASCII text — passes through unchanged unless you switch
an option on. Unescaping accepts the eight
short escapes and \uXXXX with exactly four hex
digits; surrogate pairs combine; a lone surrogate is passed
through with a note (matching JSON.parse);
anything else is an error with its position, because a
lenient decoder is how invalid strings get written into
files that stricter parsers then reject.
Worked example
The raw text — a path, a quote, and a real newline:
C:\temp\"quoted"
next line
escapes to the literal:
"C:\\temp\\\"quoted\\\"\nnext line"
Every backslash in the path is doubled, the quotes are
escaped, and the newline became the two characters
\n — paste it into any JSON document and every
conforming parser hands back the original text byte-for-byte.
Frequently asked questions
What exactly does Escape produce?
A complete JSON string literal — surrounding quotes included — that you can paste into a JSON document, a config file, or source code. The escaping follows the JSON grammar exactly: quotes and backslashes get their backslash, the familiar control characters use the short forms (\n, \t, \r, \b, \f), and the rest of the C0 control range becomes \u00XX. Nothing else is touched: forward slashes and non-ASCII characters pass through raw unless you ask for the options below, because JSON itself does not require them escaped.
Why are there options for escaping / and non-ASCII if JSON doesn't need them?
For the pipelines around JSON rather than JSON itself. \/ is legal JSON and some non-JSON grammars that borrow JSON strings (and some very old parsers) are happier with slashes escaped — the classic case is a literal containing </script> inside an HTML page. Escaping non-ASCII as \uXXXX (astral characters become a surrogate pair of escapes) is for toolchains that still mangle raw UTF-8. Both options produce strictly valid JSON; both are off by default because the default output is what JSON tooling expects to see.
Unescape rejected my string with 'invalid escape sequence'. Isn't \x41 obviously an A?
In JavaScript source, yes; in JSON, no — and the difference is the point of this tool. JSON's escape list is exactly eight short forms plus \uXXXX. A tool that quietly accepts \x, \d or \' inside a JSON string teaches a dialect that every real JSON parser will reject later, at a worse moment, with a worse error. So unescaping is strict: unknown escapes, short \u sequences, trailing backslashes and raw control characters (including a literal newline inside the quotes) are errors with a line and column, never silent pass-throughs.
Can I paste the string with or without its surrounding quotes?
Either. If the input opens with a double quote it is treated as a full literal: it must close, and anything but whitespace after the closing quote is an error (that strictness catches the classic pasted-two-strings-by-accident case). Without the opening quote, the input is treated as the escaped body — which is what you get when you copy the inside of a string out of a JSON file. Both paths apply the same escape validation.
What happens to a lone surrogate escape like \uD83D on its own?
It is passed through as-is, and flagged in a note under the result. That matches JSON.parse's behaviour, but the resulting character cannot be encoded as UTF-8, so most downstream pipelines will reject or replace it — the note exists so you find that out here rather than there. A proper pair (\uD83D\uDE00) combines into the astral character it encodes, as it should.
Is this the same as encodeURIComponent or a Base64 encoder?
No — those solve different problems. encodeURIComponent percent-encodes text for URLs; Base64 encodes bytes for transport. This tool converts between raw text and the JSON string literal form of that text, for the daily work of embedding a log line, a file path or a paragraph into a JSON document (or recovering the original from one) without hand-counting backslashes.
Dev