JSON Escape Characters: How to Escape Quotes, Backslashes, and Unicode

Quick answer: Inside a JSON string, escape a double quote as \", a backslash as \\, a newline as \n, and a tab as \t. Any other character can be written as \uXXXX. Nothing else needs escaping. The surest way to get it right is to let a serializer such as JSON.stringify() do it for you.

A customer's address contains a quotation mark. A log message has a Windows file path. A product description includes a line break. Each one is ordinary text, and each one will break your JSON if it is pasted in raw. Escaping is the small set of rules that makes any text safe inside a JSON string, and the rules are short enough to memorize.

Use the JSON Escape / Unescape tool to inspect quoted strings and backslashes without editing escape sequences by hand.

Why JSON Strings Need Escaping

A JSON string starts and ends with a double quote. So the parser needs a way to tell the difference between a quote that ends the string and a quote that is part of it. The backslash is that signal: \" means "this quote is content". Because the backslash now has a special job, a literal backslash needs its own escape, \\.

The third group is control characters: raw line feeds, tabs, and other invisible bytes below U+0020. The spec forbids them unescaped because they are invisible, easy to corrupt in transit, and ambiguous across operating systems. They get the familiar \n, \t notation instead.

The Complete JSON Escape Sequence Table

JSON defines exactly nine escape sequences. There are no others; \x41, \0, \', and \v are all invalid even though some languages accept them.

Three of these are mandatory in the sense that the raw character is illegal: \", \\, and the control characters. The forward slash escape is optional. Everything else, including é, 日本, and emoji, may appear literally as long as the file is UTF-8.

Escaping Quotes and Backslashes

The two cases that account for most escape bugs:

{
  "quote": "He wrote \"ship it\" on the board",
  "path": "C:\\Users\\priya\\reports",
  "regex": "^\\d{3}-\\d{4}$"
}

Read the path line carefully: each backslash in the real path is doubled in the JSON text. When a parser reads it, every \\ collapses back to a single \, so the application sees C:\Users\priya\reports. The same applies to the regular expression, which is why regex patterns stored in JSON look twice as hairy as they are.

Escaping Newlines and Tabs

A multi-line value is written on one line with \n markers:

{
  "address": "42 Harbour St\nSuite 7\nSydney NSW 2000",
  "tsv": "sku\tqty\tprice"
}

Pressing Enter inside a JSON string instead of typing \n produces the error Bad control character in string literal. Our common JSON errors guide shows that message alongside the other nine that waste the most time.

Unicode: \u Escapes, UTF-8, and Emoji

\uXXXX writes any character by its 16-bit code unit in hexadecimal. It is handy when a file must stay pure ASCII, for example when it passes through a system that mangles encodings:

{
  "city": "Z\u00fcrich",
  "arrow": "\u2192",
  "rocket": "\ud83d\ude80"
}

The last line is the trap. Characters outside the Basic Multilingual Plane, which includes almost every emoji, do not fit in four hex digits. JSON represents them as a surrogate pair: two \u escapes that the parser combines. Writing \u1F680 does not work; the parser reads \u1F68 followed by a literal 0.

In practice, prefer literal UTF-8. It is shorter, readable, and every modern parser handles it. Reach for \u only when a downstream system demands ASCII. Python's json.dumps() escapes non-ASCII by default; pass ensure_ascii=False to keep characters literal.

Let the Serializer Escape for You

Hand-escaping is for reading JSON and for the odd fixture file. For anything generated by code, build an object and serialize it. The library handles every case, including ones you forgot:

// JavaScript
const note = { text: 'Path "C:\\temp"\nDone\tOK' };
JSON.stringify(note);
// {"text":"Path \"C:\\temp\"\nDone\tOK"}

# Python
import json
json.dumps({"text": 'Path "C:\\temp"\nDone'}, ensure_ascii=False)
# {"text": "Path \"C:\\temp\"\nDone"}

The same rule applies in reverse. Never strip quotes or backslashes with string replacement; call JSON.parse() and read the value. The JSON.parse() and JSON.stringify() guide covers the edge cases, such as how stringify treats lone surrogates.

The Double-Escaping Problem

The most common escaping bug is not a missing escape but one applied twice. It happens when JSON is stored inside JSON, for example a webhook payload saved as a string field in a log event:

{
  "event": "webhook",
  "body": "{\"orderId\": 1042, \"note\": \"Say \\\"thanks\\\"\"}"
}

That inner body is a valid JSON string containing valid JSON text, but each nesting level doubles the backslashes. Two signs you have double-escaped by accident:

• Values arrive on the other side with literal \n characters instead of line breaks.
• You see \\\" sequences in a field that was supposed to hold plain text.

The fix is architectural: serialize once, at the boundary, and pass objects rather than pre-serialized strings through your code. If nesting is unavoidable, document it and parse the inner string explicitly on the way out.

Fixing "Bad Escaped Character" Errors

SyntaxError: Bad escaped character in JSON at position 37 means a backslash is followed by something not in the table above. Work through it in order:

1. Paste the document into JSON Prettifier and click Validate to get the line and column.
2. Look at the character after the backslash. If it is a letter like d, s, U, or a digit, you have an unescaped Windows path, regex, or LaTeX.
3. Double every backslash that should be literal.
4. If the character is a single quote (\'), remove the backslash. Single quotes are not special in JSON.
5. Validate again. Repeat until the file parses, then Format it to confirm the values look right.

If the error mentions an unterminated string instead, the likely cause is an unescaped double quote that ended the string early. The JSON parse error guide walks through that one.

When the escaped value is a schema pattern, use these JSON Schema regex checks to verify that the parsed expression still matches the intended values. Valid JSON escaping alone does not prove correct pattern behavior.

Security Note: Escaping Is Not Sanitizing

JSON escaping protects the JSON structure. It does nothing to protect the place the value ends up. A string like "<script>alert(1)</script>" is perfectly valid JSON; it becomes a problem only when inserted into HTML without HTML escaping. Treat the two as separate steps, and when embedding JSON directly in a <script> tag (for example JSON-LD structured data), escape < as \u003c. More on this in JSON security best practices.