What does the JSON Escape / Unescape tool do?
It takes a piece of text and turns it into something you can drop between two quotes in a JSON file — and it reads one back out again. Paste He said "hi" and you get He said \"hi\" back, with the line underneath reading 12 characters in → 14 out, 2 escaped. That last number is the useful one: it tells you how much of your paste actually needed touching, and a zero tells you it was already safe to use as it stood.
Escape is the direction that's selected when the page loads, because it's why most people arrive. Switch to unescape and the same conversion runs backwards: paste \ud83d\ude00 and one 😀 comes out, a surrogate pair recombined into a single character. Neither direction requires your input to be valid JSON. A SQL query, a stack trace, a shell command, a whole JSON document, or one stray word with a quote in it all go through the same way. Far more people search for a JSON escape tool than a JSON unescape one, which is why the default sits where it does — but both halves of the job live on this one page.
The conversion runs in your browser, recomputing as you type on a 120 ms delay, so there's no Escape button to hunt for. Your text never leaves the machine. That matters more here than it does for most text tools, because the strings people need to escape a JSON string for are usually connection strings, bearer tokens, customer records, or the body of the request that just failed in production.
Which characters JSON makes you escape
The list is shorter than people expect, and it never changes — which means you can learn to escape JSON strings by eye and use the JSON Escape / Unescape tool for speed rather than for rescue. JSON requires an escape for exactly three groups of characters: the double quote, the backslash, and everything below U+0020. Five of those control characters have a one-letter shorthand; the rest are written as \u plus four hex digits.
| Character | Becomes | Where it usually comes from |
|---|---|---|
| " | \" | A quoted table name in SQL, an HTML attribute, a message that quotes someone. |
| \ | \\ | A Windows path, a regular expression, a LaTeX command, an escape you already applied. |
| newline | \n | Any multi-line paste at all — a stack trace, a query, an email body. |
| carriage return | \r | Files written on Windows, HTTP headers, anything that travelled over a terminal. |
| tab | \t | Pasted TSV, indented code, log lines with aligned columns. |
| backspace | \b | U+0008. Interactive terminal captures, occasionally a broken editor. |
| form feed | \f | U+000C. Page breaks in text extracted from a PDF. |
| anything else below U+0020 | \u00XX | ANSI colour codes from coloured console output, a stray null from a binary read. |
Nothing else is required. Accents, CJK, emoji and the forward slash are all legal as themselves — JSON permits \/ but has never asked for it, so this tool leaves slashes alone.
If the summary says 0 escaped, your text contained none of the characters above and you can paste it between quotes untouched. That's a real answer, not a failure — plenty of pastes come back unchanged.
How the escaping works, character by character
The escape direction walks your text one UTF-16 code unit at a time. Quotes and backslashes get doubled up, the five named control characters get their shorthand, and any remaining character under U+0020 is written out in hex. Everything above that is copied through as itself, so café 😀 comes out as café 😀 — 7 characters in, 7 out, 0 escaped. That output is already valid JSON, and it stays readable in a diff.
Turn on Escape non-ASCII as \uXXXX and the same input becomes caf\u00e9 \ud83d\ude00: 7 characters in → 22 out, 3 escaped. Three, not two, because the emoji lives above U+FFFF and JSON writes such characters as the surrogate pair UTF-16 uses internally. Both forms parse to the identical string, so this is never a correctness question — only a question of whether the JSON has to survive a pipeline that isn't reliably UTF-8. One exception is not optional: half an emoji, a lone surrogate with no partner, is always escaped, because it has no valid encoding as itself.
The unescape direction is a hand-written scanner rather than a call to a JSON parser, and that choice is the point of the page. A parser rejects the two things people paste most often — a value copied with its outer quotes still attached, and a value carrying a raw newline from wherever it was copied — and it rejects them with a message that names a byte offset instead of the problem. So this scanner strips one matched pair of outer quotes if it finds them, keeps raw newlines, raw tabs and stray quotes as content, and reserves its errors for the three sequences that genuinely have no reading: an unknown escape, a truncated \u, and a backslash with nothing after it. Each one names the sequence and counts the position from the first character you can see.
Pages that do this job have a habit of growing into something else. The same four lines of string handling turn up as one tab inside a fifty-tool dashboard that wants an account before it will show you a backslash, or behind a fourteen-day trial, or bundled into a per-seat subscription somebody in procurement has to cancel. Escaping a quote is not a subscription business. This page escapes and unescapes, and that's the whole of it.
Worked examples in both directions
Every pair below is the exact output of the JSON Escape / Unescape tool, defaults on unless the row says otherwise.
| What you paste | What comes out | The summary line |
|---|---|---|
| He said "hi" | He said \"hi\" | 12 in → 14 out, 2 escaped |
| He said "hi" — Wrap in quotes on | "He said \"hi\"" | 12 in → 16 out, 2 escaped |
| C:\new | C:\\new | 6 in → 7 out, 1 escaped |
| a, newline, tab, b, U+0007 | a\n\tb\u0007 | 5 in → 12 out, 3 escaped |
| \n (typed as two characters) | \\n | 2 in → 3 out, 1 escaped |
| café 😀 | café 😀 | 7 in → 7 out, 0 escaped |
A longer one, the shape this actually comes up in. Take a two-line query with a quoted table name: SELECT * FROM "users", a real line break, then WHERE name = 'O''Brien';. Escaped, it becomes SELECT * FROM \"users\"\nWHERE name = 'O''Brien'; — 46 characters in → 49 out, 3 escaped. Two double quotes and the line break moved; the single quotes didn't, because JSON has no opinion about them.
Going the other way, three cases worth seeing. Paste "\"quoted\"" — a value copied straight out of a log, outer quotes included — and you get "quoted", with a note telling you one matched pair came off before reading and the inner pair was kept as content. Paste a\/b and you get a/b, since an escaped forward slash is legal even though nothing requires it. Paste \ud83d\ude00 and you get 😀: 12 characters in → 2 out, 2 escape sequences resolved.
The Swap button moves the output into the input box and flips the direction. One click sends a result back through the opposite conversion, and if your original text returns unchanged, the escape was right.
Where JSON escaping goes wrong
Almost every broken payload traces back to one of five things.
A Windows path that was never doubled. Unescape C:\Users\new and you get \U isn't a JSON escape sequence (character 3). Drop the backslash, or use \\ if you meant a literal one. The position counts from 1, through the string exactly as you pasted it, so you can count straight to the offending character. In the escape direction the same path needs no thought at all — each backslash simply doubles.
A payload escaped twice. If you see \\n in a value where you expected a line break, the string went through an escaper on its way into a field that then escaped the whole thing again. Nested API payloads do this constantly. Unescape JSON that arrived wrapped inside another field once, then look at what you have: if the result still reads as escapes rather than text, run it through again.
Assuming JSON takes the escapes your language does. It doesn't, and the JSON Escape / Unescape tool won't pretend otherwise. \x41, \0, \' and a backslash before a real line break are all fine in JavaScript or Python source and all illegal in JSON. Only eight letters follow a backslash in a JSON string, plus u and four hex digits.
Counting characters when something downstream counts bytes. café 😀 is 7 UTF-16 code units and 10 UTF-8 bytes. A varchar limit, a payload cap and a rate limiter usually mean bytes; the character counters in your editor usually mean code units. Escaping widens the gap, since every newline that becomes \n costs a byte more than it did.
Reading the output instead of the error. When the unescape direction fails it says which sequence broke and where. That message is almost always faster than re-reading the string, because a single stray backslash in a 4,000-character blob is invisible until something points at it.
Related developer tools
The JSON Escape / Unescape tool does one step of a longer job. Once your string is inside a document, the JSON formatter indents it and tells you whether the syntax parses, and the JSON diff shows what changed between two versions of a response. If the text is heading into a query string or an HTML attribute rather than a JSON string, the rules are different and so is the tool — use the URL encoder and decoder or the HTML encoder and decoder instead. For payloads that have to travel as plain ASCII regardless of content, the Base64 encoder and decoder is the blunter instrument. And when the shape of the data changes rather than its encoding, the JSON to YAML converter and the CSV to JSON converter handle those trips.
Frequently asked questions
Is JSON escaping the same thing as URL encoding or Base64?
No — three different jobs with three different rulebooks. JSON escaping protects a string from the JSON grammar, so quotes, backslashes and control characters get backslash sequences and nothing else moves. URL encoding protects a string from a URL, turning spaces into %20 and reserved characters into percent codes. Base64 re-encodes arbitrary bytes into 64 safe ASCII characters and makes the result unreadable but transport-proof. Applying the wrong one usually still produces valid-looking output, which is why the mistake tends to survive until something on the other end reads it back.
Do single quotes need to be escaped in a JSON string?
Never. JSON strings are delimited by double quotes only, so an apostrophe is an ordinary character and don't goes in exactly as it stands. If you're seeing doubled single quotes like O''Brien, that's SQL escaping its own string delimiter, and it should stay doubled — it's part of the query text you're embedding, not something JSON introduced. The confusion comes from JavaScript, where both quote characters delimit strings; JSON only inherited one of them.
Which number should I check against a database column — characters or bytes?
Usually bytes. The tool reports the input and output length in UTF-16 code units, which is what an editor's character count shows, and it measures its own 5 MB ceiling in UTF-8 bytes, which is what column limits, payload caps and rate limiters normally mean. The two diverge the moment you leave ASCII: an accented letter is one unit and two bytes, an emoji is two units and four bytes. If a value is close to a limit, assume bytes and give yourself room. The character counter is the tool for the other side of that question.
JavaScript and Python let me write \x41 and \0. Why does JSON reject them?
Because JSON's escape list is deliberately tiny: \", \\, \/, \b, \f, \n, \r, \t, and \u followed by four hex digits. That's all of it. There's no hex escape, no octal escape, no null shorthand, no line continuation. So a snippet of source code pasted into a JSON field will often carry escapes that look reasonable and parse nowhere. Escaping that snippet first is the fix: each backslash doubles, and the sequence survives as the literal text it was.
Does the case of an escape matter? Is \U0041 valid?
The u must be lowercase — \U0041 is not a JSON escape and the unescape direction says so, naming the position. The four hex digits after it can be either case, so \uD83D\uDE00 and \ud83d\ude00 both resolve to the same emoji. When this tool writes escapes itself it uses lowercase throughout, matching what every serialiser emits.
Can I escape a whole JSON document and put it inside another JSON string?
Yes, and it's a normal thing to do — webhook envelopes, message queues and audit logs all carry a JSON payload as a string field. Paste the document into the escape box and every quote and line break in it is handled; the result is one long line you can drop into the outer value. Remember that you'll need to unescape once to read it back, and that the character count grows sharply, because a document full of quotes is a document full of two-character escapes.
What happens to Windows line endings — do I lose the carriage return?
Nothing is lost. A CRLF pair becomes \r\n in the output, two escapes rather than one: a, CRLF, b is 4 characters in → 6 out, 2 escaped. Unescaping puts both characters back exactly as they were, so a round trip through the JSON Escape / Unescape tool preserves the line endings a file arrived with rather than quietly normalising them. Using the tool costs nothing and needs no account — and 10% of every dollar Microapp earns goes to charity, off the top, audited quarterly.