Escape sequences in JSON strings: the complete valid set

JSON allows exactly nine escape sequences inside a string, no more. Every backslash in a JSON string must begin one of them or the document is invalid. This is a much shorter list than most languages, and that is the source of a whole class of errors: people reach for \d, \x41, or a literal newline and the parser rejects it.

The complete list

A JSON string is wrapped in double quotes. Inside, a backslash may only introduce these:

That is the entire set. There is no \x41, no \0, no \a, no \e, no octal. Anything else after a backslash, such as \d or \z, is an invalid escape and the parser throws.

What you must escape

Three things are mandatory inside a JSON string:

1. The double quote ", otherwise it would end the string early.
2. The backslash \, otherwise it would start an escape.
3. Control characters in the range U+0000 to U+001F. A literal newline or tab byte inside a string is illegal. You must write \n or \t instead.

Everything else can appear literally. The forward slash is the notable one: \/ is allowed but never required. You can write "https://example.com" with bare slashes and it is perfectly valid. The \/ escape exists only so that JSON can be embedded safely inside an HTML <script> tag without the sequence </ closing it prematurely. If you see http:\/\/ in output, that is a tool being cautious, not a requirement.

The invalid-escape errors

{ "pattern": "\d{3}" }

This is invalid JSON. \d is not on the list. JSON.parse reports Bad escaped character in JSON. The fix is to escape the backslash itself: "\\d{3}". This bites constantly when people store regular expressions in JSON, because a regex is full of \d, \w, \s, and \., none of which JSON recognizes. Every one of those backslashes must be doubled.

Windows file paths hit the same wall:

{ "path": "C:\Users\me" }

\U and \m are both invalid escapes. The path must be "C:\\Users\\me", or use forward slashes, which Windows accepts in most contexts anyway.

The double escaping trap

When JSON holds a value that is itself JSON, or a shell command, or a regex, the escaping stacks. A tab character written for a shell is \t, but to store that literal two character string \t in JSON you write \\t. To store a newline character you write \n. The question to ask every time is whether you want the actual control character or the two literal characters backslash and t. They are different strings and the backslash count encodes which one you mean.

Verifying

The quickest way to catch a stray or doubled backslash is to parse the string and read it back. A value that round trips without error and shows the characters you intended is correct. The JSON Formatter validates escapes locally and names the exact position of a bad one, which is far faster than counting backslashes by eye.