JSON escaping rules

October 14, 2026 · 12 min read

JSON strings are delimited by double quotes. Any literal quote, backslash, or control character inside the value must be escaped or parsers throw Unexpected token. Logs, SQL exports, and hand-built API bodies are the usual sources of broken escaping - not the JSON spec itself.

Why escaping exists

Without escapes, {"msg":"He said "hi""} ends the string at the wrong quote. Escaping marks special characters so the parser treats them as data, not syntax.

Double quote: `\"`

Inside a string, write \" for each literal ". Example: "Hello \"World\"" parses to Hello "World".

Backslash: `\\`

A literal backslash is \\ in JSON source - one backslash in the parsed string. Paths like C:\\Users\\dev need every backslash doubled. Regex patterns embedded in JSON strings are a common footgun.

Newline: \n

Raw line breaks inside strings are invalid in strict JSON. Use \n for LF or \r\n for CRLF. Multi-line prose in APIs should be one escaped string or an array of lines - not unquoted paragraphs between keys.

{
  "title": "Line 1\nLine 2",
  "path": "C:\\data\\file.json"
}

Unicode and control characters

Use \u0041 for Unicode escapes when needed. Control chars (tab \t, form feed, etc.) must not appear raw. Let JSON.stringify in JavaScript or your language’s encoder produce escapes - avoid building JSON by string concatenation.

Paste suspicious payloads into the JSON validator to locate the exact bad character, then re-encode with the JSON formatter on a corrected object.

FAQ

Are single quotes valid JSON strings?: No. JSON requires double-quoted strings. Single quotes appear only inside the value after escaping.
Does pretty printing fix escaping?: Only if input is already valid. Invalid escapes must be fixed in the source string.
What about JSON in SQL strings?: You may need two layers of escaping - SQL string rules plus JSON rules.

Browse all tools