Free JSON Escape / Unescape

Escape special characters in a string for safe JSON embedding, or unescape an escaped JSON string back to plain text.

How It Works

  1. Paste your string: Enter the text you want to escape, this could be raw text containing quotes, newlines, backslashes, or any special characters.
  2. Choose escape or unescape: Select whether you want to escape text for embedding in JSON, or unescape a JSON string back to readable text.
  3. Copy the result: The escaped or unescaped output appears instantly. Copy it for use in your code or data.

Why Use JSON String Escape?

JSON strings have strict escaping rules, double quotes must become \", newlines become \n, backslashes become \\, and tabs become \t. Failing to escape these characters correctly causes JSON parse errors that break APIs, configuration files, and data pipelines. This tool handles all escaping and unescaping automatically, eliminating manual find-and-replace and preventing subtle bugs from missed escape sequences.

Features

Frequently Asked Questions

What characters does JSON escaping handle?

JSON requires escaping: double quotes ("), backslash (\), forward slash (/), newline (\n), carriage return (\r), tab (\t), form feed (\f), backspace (\b), and Unicode characters above U+FFFF. This tool handles all of them.

Why is my JSON parse error caused by escaping?

Common causes include unescaped double quotes inside a string value, literal newlines inside a string (must be \n), and unescaped backslashes. Paste your broken string here to escape it correctly.

Does this include the surrounding quotes?

By default the tool escapes the content without wrapping quotes, so you can paste the result into your JSON string. Toggle the "Include quotes" option if you want the output wrapped in double quotes.

The JSON String Spec, in One Table

RFC 8259 (December 2017, by Tim Bray) is the current JSON standard, replacing RFC 7159 and the original RFC 4627. Section 7 of the spec lists exactly which characters MUST be escaped inside a string literal:

Character Escape Code point Meaning
"\"U+0022quotation mark (ends the string)
\\\U+005Cbackslash (starts an escape)
\b\bU+0008backspace
\f\fU+000Cform feed
\n\nU+000Aline feed (LF)
\r\rU+000Dcarriage return (CR)
\t\tU+0009tab
/\/U+002Fsolidus (optional, but useful for HTML embedding)
control\uXXXXU+0000–U+001Fany C0 control character not covered above

Equivalent rules are in ECMA-404 (2nd edition, December 2017), kept in sync with the IETF spec. JSON has no octal (\012) or hex (\x41) escapes, those are JavaScript-only; JSON only supports the eight named escapes above plus \uXXXX.

The \uXXXX Escape and the Surrogate-Pair Trap

JSON's \uXXXX sequences encode UTF-16 code units, not Unicode code points. That matters for emoji and supplementary-plane characters. A single emoji like 😀 (U+1F600) escapes not as ὠ0 (that's not even a legal four-hex-digit form), but as a surrogate pair: 😀, two consecutive escapes encoding the high and low surrogates. The high-surrogate range is U+D800–U+DBFF; the low-surrogate range is U+DC00–U+DFFF; together they cover U+10000 through U+10FFFF (the supplementary planes).

This is the most common source of escaped-emoji bugs. RFC 8259 Section 7 explicitly says: "To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a 12-character sequence, encoding the UTF-16 surrogate pair." A family-of-four emoji like 👨‍👩‍👧‍👦, which is technically four base emoji plus three zero-width joiners, escapes as 30+ characters in a JSON string. The byte count balloons accordingly: 25 UTF-8 bytes raw, ~58 bytes JSON-escaped.

JSON Inside HTML, URL, SQL, and CSV

JSON-escaping by itself isn't enough when the JSON is embedded in another format. Each context adds its own layer.

JSON inside HTML. The classic trap is <script>const data = {{ payload | json }};</script> when the payload contains the literal substring </script>. The HTML parser closes the script tag mid-string and the rest of the JSON renders as visible text on the page. The fix is the optional \/ escape: <\/script> is JSON-valid and HTML-safe. OWASP's cross-site-scripting cheat sheet recommends always escaping <, >, &, and ' in JSON intended for HTML embedding.

JSON inside a URL query string. Two layers: first JSON-escape, then percent-encode. {"name":"Bob"} becomes %7B%22name%22%3A%22Bob%22%7D. Forgetting the percent-encoding is the #1 cause of malformed JSON-in-URL bugs.

JSON inside SQL. Stored in a PostgreSQL jsonb column the value is parsed natively, no further escaping needed. But JSON embedded in a SQL string literal (INSERT INTO t (data) VALUES ('{"key":"value"}')) needs SQL-string escaping on top of JSON: single quotes doubled (''), or better, use parameterised queries.

JSON inside CSV cells. CSV's quoting differs from JSON's (CSV uses doubled quotes "", not backslash sequences). Embedding JSON in a CSV cell needs both layers: JSON-escape the string, then CSV-escape the result (wrap in "...", double any internal ").

Runtime APIs Across Languages

Language Encode Decode Notes
JavaScriptJSON.stringifyJSON.parseNative since IE 8 (2009). Available in every browser and Node.
Pythonjson.dumpsjson.loadsensure_ascii=False opts out of \uXXXX escaping for non-ASCII.
PHPjson_encodejson_decodeNative since PHP 5.2 (Nov 2006). Flag JSON_UNESCAPED_UNICODE since 5.4.
JavaObjectMapper.writeValueAsStringreadTreeJackson is the de-facto standard since ~2009.
Gojson.Marshaljson.UnmarshalStandard library encoding/json.
Rustserde_json::to_stringserde_json::from_strThe serde_json crate, ubiquitous.

Where JSON Came From, And What Crockford Left Out

JSON was first formalised by Douglas Crockford in 2001 at State Software, originally to serialise JavaScript objects for asynchronous data exchange. The first public mention was at the 2003 JSON.org site. Crockford specified it formally as RFC 4627 in July 2006, partly to combat a competing patent attempt around the same time. The standard moved to STD 90 status with RFC 8259 in December 2017.

JSON's biggest design decision was making it a subset of JavaScript, so any JSON document could be eval'd in a JS interpreter and yield the correct value. This made browser adoption frictionless but locked in some JS quirks permanently: no integer type (all numbers are IEEE 754 doubles), no date type, no NaN or Infinity. Big integers above 2⁵³−1 need string serialisation ("id": "9007199254740993") to avoid silent precision loss.

Crockford deliberately left out things you might miss: comments ("I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability", May 2012), trailing commas, and schema language (added later as JSON Schema, separately maintained, current draft 2020-12). The community variant JSON5 restores comments and trailing commas but is not RFC-compliant; it's used mainly in config files (.babelrc, .swcrc) where humans edit.

Common Use Cases

Common Mistakes

  1. Using JavaScript escapes that aren't JSON-valid. \x41 for "A" and \012 for newline are valid in JS string literals but invalid in JSON. JSON only allows the eight named escapes plus \uXXXX.
  2. Using single quotes for JSON strings. 'hello' works in JavaScript but is invalid JSON. JSON strings MUST use double quotes.
  3. Unquoted object keys. {name: "Bob"} works in JavaScript but is invalid JSON. Keys MUST be string literals in double quotes.
  4. Trailing commas. [1,2,3,] works in JS but is invalid JSON. RFC 8259 explicitly forbids them.
  5. Inline comments. // foo and /* foo */ are invalid in standard JSON. Use JSON5 if you need comments; expect that not every parser will accept it.
  6. Hand-escaping an emoji as a single \uXXXX. Emoji above U+FFFF need a UTF-16 surrogate pair, two \uXXXX escapes back-to-back.

More Frequently Asked Questions

Should I always escape the forward slash /?

No, the forward slash / is allowed unescaped in JSON; the escape \/ is optional. The exception is when JSON is embedded inside an HTML <script> tag: escaping / as \/ prevents the literal substring </script> from closing the tag prematurely. Some encoders (JSON_HEX_TAG in PHP, custom JS replacements) do this; most do not.

Why does JSON.stringify escape my non-ASCII characters?

It doesn't, by default. JSON.stringify("café") in JavaScript produces "café" with the literal é. What you may be seeing is a different library: Python's json.dumps defaults to ensure_ascii=True and escapes everything outside ASCII as \uXXXX; PHP's json_encode behaves similarly unless you pass JSON_UNESCAPED_UNICODE. Both behaviours are valid JSON, but the file size and readability differ.

Can JSON store binary data?

Not directly. JSON strings are sequences of Unicode characters, not bytes. The standard workaround is to Base64-encode the binary first, then store the resulting ASCII string as a normal JSON value. The encoded data is ~33% larger than the raw bytes. For very large binaries, use a binary format like BSON, MessagePack, or CBOR, or store the bytes separately and reference them by URL.

Why do some tools show é instead of é?

Both are valid JSON for the same character. "café" and "café" decode to identical strings. Some encoders escape non-ASCII for maximum cross-encoding safety (the output is pure ASCII so the consumer's encoding doesn't matter), others preserve the original UTF-8 for readability. Pick based on what consumes your JSON.

Is my text uploaded anywhere?

No. The tool uses the browser's native JSON.stringify and JSON.parse APIs entirely client-side. There is no network call, no analytics, no logging. Safe for escaping API tokens, internal data, or anything you wouldn't paste into a server-side escape tool.

Related Tools

JSON Formatter JSON Tree Viewer JSON Path Extractor HTML Entity