JSON Escape Tool

JSON escaping is the process of converting special characters in JSON strings to escape sequences. Common escape characters include: double quotes to \" , backslash to \\, newlines to \n, tabs to \t, etc. Use cases: When you need to embed JSON within another JSON string, define JSON string constants in code, or store JSON data in a database, escaping is required. JSON escaping prepares text so it can be placed safely inside a JSON string. Quotes, backslashes, line breaks, tabs, and control characters need correct escaping or the parser may treat them as structure instead of content. Common targets include API payloads, configuration values, logs, embedded error messages, and test data. Escaping a string does not validate the entire JSON document, and it does not automatically make the result safe for HTML, JavaScript, SQL, or shell contexts.

JSON (RFC 8259) is a strict text grammar; every string literal must be wrapped in ASCII double quotes (U+0022), and any character that could break that grammar must be expressed as a backslash escape. The mandatory escapes are: double quote to backslash-quote, backslash to double-backslash, and the 32 control characters from U+0000 to U+001F (which include \b U+0008, \f U+000C, \n U+000A, \r U+000D, \t U+0009). Any character above U+001F may appear in the string as its raw UTF-8 byte sequence, including CJK ideographs, emoji, accented letters, and other supplementary characters. The forward slash character is optional to escape (\/), but the convention is to escape it when the JSON is embedded inside HTML <script> tags, so that the closing-script-tag sequence does not close the surrounding script element prematurely. Two layers of escaping show up in practice. JSON escape (the syntactic substitution) is the only one RFC 8259 requires: it ensures the string is valid JSON, period. Unicode escape (rewriting each character as \uXXXX or \u{XXXXX}) is a representational choice, not a syntactic requirement - it only changes how the bytes look in the file, not what they decode to. CJK text is already valid in JSON as its raw UTF-8 bytes; the page Unicode-escape mode rewrites it as \uXXXX, which is useful when feeding the string into a Java or JavaScript source file where the surrounding parser would otherwise have to deal with multi-byte UTF-8, but it adds 4-6 bytes per character and obscures readability. The escape rules have corner cases. JSON.parse is strict about leading zeros (01 is a parse error, even though JavaScript would accept it as octal 1); JSON.stringify in V8 always produces minimum-necessary escapes (control characters as \b/\n/\r/\t/\f when possible, otherwise as \uXXXX, and the solidus /, U+2028, U+2029 are left raw for human-readable output). A lone surrogate (a high surrogate not followed by a low surrogate) is technically valid JSON per RFC 8259, but JSON.parse in strict mode or in TypeScript rejects it as InvalidString; the page escape mode replaces lone surrogates with \uFFFD (replacement character) so the output round-trips through any standard parser. For JavaScript source-code embedding, the JSON string needs a third escape layer: JSON inside a JS string literal must escape the backslashes themselves. The page JS string output mode adds that double-escape, and the eval or JSON.parse button shows that the two encodings decode to the same string. Embedded-in-HTML contexts add a fourth layer: <, >, & need HTML entity escaping in the surrounding page, and attribute values need quote-escaping too. JSON-in-HTML is famously dangerous (the </script> pitfall above) and is best avoided in favour of safe sinks like textContent assignment or JSON.stringify into a <script type="application/json"> block (read later via script.textContent, never eval). JSON5 (a popular superset) adds single-quoted strings, multi-line strings, unquoted keys, trailing commas, NaN/Infinity, and single-line // comments. The page does not produce JSON5 output; if you need to round-trip, use a dedicated library.

• JSON strings (RFC 8259) must escape double quote to backslash-quote, backslash to double-backslash, and the 32 control characters U+0000..U+001F (\b \f \n \r \t, plus the rest as \uXXXX). Everything above U+001F is valid raw UTF-8, including CJK, emoji, and accented letters.
• Two layers of 'escape' show up: JSON escape (syntactic, required) makes the string valid JSON; Unicode escape (representational) rewrites characters as \uXXXX and only changes readability, not validity.
• Optional '/': / to \/ is allowed in JSON. Convention: escape it when embedding JSON in HTML <script> so the closing-script-tag sequence does not close the surrounding tag.
• CJK is not escaped in raw UTF-8 JSON: the example '你好' is 6 raw bytes. The page Unicode-escape mode rewrites it as \u4f60\u597d for use in source files, which trades readability for compatibility.
• Lone surrogates: a high surrogate (U+D800..U+DBFF) not followed by a low surrogate is technically valid JSON per RFC 8259, but JSON.parse in strict mode or TypeScript rejects it. The page replaces lone surrogates with \uFFFD so the output round-trips through strict parsers.
• JSON.parse is strict: leading zeros (01) are a parse error, NaN/Infinity are not valid literals, trailing commas are not allowed. JSON.stringify in V8 always produces minimum-necessary escapes and leaves solidus / and U+2028/U+2029 raw for readability.
• JSON-in-JS: to embed a JSON string in a JS string literal, double the backslashes. The page 'JS string' output adds that layer; eval on the result gives the same string as JSON.parse.
• JSON5 superset: single-quoted strings, multi-line strings, unquoted keys, trailing commas, NaN/Infinity, single-line // comments. The page produces strict RFC 8259 JSON, not JSON5.