Bad Escaped Character in JSON: Every Cause and Fix

Published 6 Oct 2026 · 8 min read

JSON gives a backslash exactly one job: it starts an escape sequence, and the parser accepts only eight of them. Any other character after a backslash — the U in C:\Users, the d in a regex's \d, the apostrophe in \' — makes V8 stop with SyntaxError: Bad escaped character in JSON at position N. The position points at the character after the backslash, not at the backslash itself. Every cause below is a backslash that came from somewhere that isn't JSON (a file path, a regex, JavaScript or Python source) and was pasted into a JSON string unescaped, and each one has a live, prefilled JSON Lab example so you can watch the exact failure.

Quick reference

Every message and position below was produced by running the exact input through JSON.parse() on Node.js 22 (V8). Other engines word the error differently but the cause and the fix are the same.

1. A Windows path pasted into a JSON string

This is the most common trigger by a wide margin. Windows separates directories with the backslash, so a path copied from Explorer, a stack trace or a config file arrives with one backslash per level. In JSON each of those starts an escape sequence. \U isn't one, so the parse fails at the U:

{"path": "C:\Users\anand\file.txt"}
// SyntaxError: Bad escaped character in JSON at position 13 (line 1 column 14)
//                                          ^ the "U" right after the first backslash

The fix is to write each backslash as two. The doubled form parses to the single-backslash path you started with:

{"path": "C:\\Users\\anand\\file.txt"}

2. The lowercase variant says "Bad Unicode escape" instead

Change the path to C:\users\anand and the message changes, which sends people looking in the wrong place. \u is a valid escape — it introduces a four-digit hex code point — so the parser accepts the backslash and then fails because sers isn't hex:

{"path": "C:\users\anand\file.txt"}
// SyntaxError: Bad Unicode escape in JSON at position 14 (line 1 column 15)

Same root cause, same fix. If your error says "Bad Unicode escape", look for a stray \u — a \users path, a \uploads folder, or a \u with fewer than four hex digits after it.

3. The path that parses fine and is wrong

This is the dangerous one. Five of the eight valid escapes are single letters — \b, \f, \n, \r, \t — and Windows folders start with those letters all the time. C:\new\temp\report.txt doesn't throw. It parses without complaint into a string that isn't the path you typed:

const p = JSON.parse('{"path": "C:\\new\\temp\\report.txt"}').path;
p.length;            // 19, not 22: three backslash-letter pairs became one character each
JSON.stringify(p);   // "C:\new\temp\report.txt", read as: C, colon, NEWLINE, "ew", TAB, "emp", CARRIAGE RETURN, "eport.txt"
[...p].slice(0,6).map(c => c.charCodeAt(0));   // [67, 58, 10, 101, 119, 9]

The code points 10 and 9 are the newline and tab. Nothing fails until the string reaches a file API that can't open a path with a line break in it, and by then the error is nowhere near the JSON. If a parser doesn't reject a Windows path, don't assume it was written correctly: check for paths containing \n, \t, \r, \b or \f after any backslash-letter folder name (\new, \temp, \reports, \backup, \files).

4. A regular expression stored as a string

Regex syntax is built on backslashes: \d, \w, \s, \., \b. In a JavaScript regex literal that's fine. Put the same pattern into a JSON config value and every one of them is a bad escape except \b, which silently turns into a backspace character and breaks the pattern without an error:

{"pattern": "^\d{3}-\d{4}$"}
// SyntaxError: Bad escaped character in JSON at position 15 (line 1 column 16)

{"pattern": "^\\d{3}-\\d{4}$"}   // valid; parses to the string ^\d{3}-\d{4}$

After parsing, the doubled version gives you the string ^\d{3}-\d{4}$, which new RegExp() compiles correctly. Doubled backslashes in the file are the on-disk representation; they aren't extra characters in the value. To test the pattern itself before you serialize it, use Regex Lab.

5. Escapes copied from JavaScript or Python source

Several escapes are legal in string literals in other languages but not in JSON, and they're easy to carry across when you paste a literal into a JSON file:

• \': valid in JavaScript and Python, invalid in JSON. JSON strings only use double quotes, so an apostrophe never needs escaping.
• \x41: a two-digit hex escape in JavaScript and Python. JSON has no \x; use \u0041.
• \0: the NUL character in most languages. JSON rejects it; use \u0000.
• \/ works the other way: it's valid JSON (it parses to a plain /) even though most languages don't have it.

{"msg": "it\'s done"}
// SyntaxError: Bad escaped character in JSON at position 12 (line 1 column 13)

{"letter": "\x41"}
// SyntaxError: Bad escaped character in JSON at position 13 (line 1 column 14)

6. UNC paths and a truncated \u escape

A network path like \\server\share\file starts with two backslashes. The first pair is a valid escaped backslash, so the parser carries on until the next lone one — the s in \share — and fails there, at position 20, nowhere near the start of the path. That's why the position can look wrong: it's the first unpaired backslash, not the first backslash. The same applies to a four-digit escape cut short:

{"share": "\\server\share\file"}
// SyntaxError: Bad escaped character in JSON at position 20 (line 1 column 21)

{"c": "\u00e"}
// SyntaxError: Bad Unicode escape in JSON at position 12 (line 1 column 13)

The real fix: stop writing the backslashes yourself

Hand-doubling backslashes works for one value and fails the first time someone edits it. If your code produces the JSON, build the value as a normal string and serialize it. JSON.stringify() escapes every backslash, quote and control character correctly:

JSON.stringify({ path: String.raw`C:\Users\anand\file.txt` });
// {"path":"C:\\Users\\anand\\file.txt"}

JSON.stringify({ pattern: String.raw`^\d{3}-\d{4}$` });
// {"pattern":"^\\d{3}-\\d{4}$"}

Two mistakes to avoid when you do this. First, don't also run a .replace(/\\/g, '\\\\') before JSON.stringify(): that doubles the escaping, and the value you read back has twice as many backslashes as the original. Second, don't use .replace(/\\/g, '/') to dodge the problem unless you really want forward slashes in the data; most Windows APIs accept them, but the value is no longer the path you were given.

Debugging checklist

1. Read the position in the message as the character after a backslash. Open the file at that offset: the backslash is the character one position earlier.
2. If the message is "Bad Unicode escape" instead, look for a \u with fewer than four hex digits after it, usually in a \users or \uploads path.
3. If the position is further along than the first backslash you can see, you have a valid \\ pair earlier in the string; the error is the first unpaired backslash after it.
4. If a Windows path parsed without error, check the result for a newline or tab: JSON.stringify(value) shows them as \n and \t.
5. Fix it at the source: serialize with JSON.stringify() rather than concatenating strings or editing backslashes by hand.
6. Paste the failing text into JSON Lab to see the exact position, and use its repair step on a copy if you only need the data out.

Related JSON errors worth telling apart from this one: Unexpected token in JSON is a wrong character in the structure itself, and Expected property name or '}' is a bad key. This one is narrower: the structure is fine, and a backslash inside a string is the only thing wrong.

← Back to Blog · See also: Unexpected Token in JSON →