JSON Escaping Explained: Quotes, Backslashes, Newlines & Unicode

Escaping is part of JSON string syntax

JSON uses double quotes to delimit strings. A character that would otherwise end the string or conflict with JSON string syntax must be represented with an escape sequence. Escaping does not change objects, arrays, numbers, booleans, or null outside string values.

A backslash introduces an escape. Standard JSON recognizes escapes for quotation mark, reverse solidus, slash, backspace, form feed, newline, carriage return, tab, and four-hex-digit Unicode code units. An unsupported sequence such as \q is invalid JSON.

Escape quotes and backslashes once per string layer

A quotation mark inside a JSON string is written as \" so it is treated as data rather than the end of the string. A literal backslash is written as \\ because a single backslash would start an escape sequence.

Paths and regular-expression text are common places to see repeated backslashes. Count the string layers before adding more escapes: JSON source has one layer, while JSON embedded inside a JavaScript, SQL, shell, or another JSON string can require an additional layer owned by that outer format.

{
  "message": "She said \"hello\"",
  "path": "C:\\temp\\report.json"
}

Newlines and control characters must be escaped

A physical line break cannot appear in the middle of a quoted JSON string. Represent it with \n. Tabs and carriage returns similarly use \t and \r when they are part of the string value.

This is different from formatting whitespace between JSON tokens. A pretty-printed object can span many lines, but line breaks inside a quoted value need escapes so the parser can distinguish data from document layout.

{
  "message": "first line\nsecond line\tindented"
}

Unicode text usually does not need escaping

JSON text can contain ordinary Unicode characters directly, including accented letters, CJK characters, and emoji when the surrounding transport uses a compatible Unicode encoding such as UTF-8. Escaping every non-ASCII character is not required for valid JSON.

A \u escape represents one UTF-16 code unit with four hexadecimal digits. Characters outside the Basic Multilingual Plane can be represented by a surrogate pair when written with \u escapes. If an escape contains non-hexadecimal text or an incomplete four-digit sequence, parsing fails.

{"city":"新加坡"}
{"city":"\u65b0\u52a0\u5761"}

Recognize escaped and double-encoded JSON

Sometimes an API field contains a JSON document as a string. The outer document must escape the quotes and backslashes that belong to the inner JSON. After parsing the outer document, the field is still a string and needs a second parse only if the application contract says that field contains JSON.

Do not blindly remove every backslash. Some backslashes are necessary data, and some belong to the outer serialization layer. Decode one layer at a time and inspect the result before parsing again.

{
  "payload": "{\"id\":1,\"active\":true}"
}

Debug escape errors systematically

Start at the parser location and inspect the nearest quotation mark and backslash. Determine whether the parser is inside a string, then identify which serialization layer owns the escape. Correct only that layer and validate again before changing other characters.

• Use \" for a quotation mark that belongs inside the current JSON string.
• Use \\ for a literal backslash in the current JSON string.
• Replace literal line breaks inside strings with \n when the newline is part of the value.
• Check every \u escape for exactly four hexadecimal digits.
• If the entire document looks backslash-heavy, test whether it is an escaped JSON string or double-encoded payload before editing it manually.