Bad escaped character in JSON at position 13

A backslash inside a JSON string begins an escape, which is a short spelling for a character that needs special treatment. The next letter must belong to JSON's small set of escape forms. In a Windows path, a separator before Users looks like an escape beginning with capital U, and JSON has no such escape. The quotes around the path do not change this rule: backslashes have to be written correctly inside those quotes as well.

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

Corrected invalid escape sequences (2)

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

Keep a literal backslash by doubling it

To store one backslash in the decoded value, put two backslashes in the JSON text. The valid document for this path is:

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

Each pair represents one separator, so a program reading that document receives the intended Windows path. Apply the same rule to every literal backslash, including ones before letters that happen to form valid escapes. A path segment beginning with temp can be more confusing than Users: a single backslash followed by t is accepted as a tab, which changes the value without producing a syntax error. Valid JSON therefore still needs a check that the decoded string matches the path you intended.

Which escapes JSON understands

JSON permits a backslash before a double quote, another backslash or a forward slash. Its letter escapes are b, f, n, r and t, representing backspace, form feed, newline, carriage return and tab. A lowercase u introduces a Unicode escape and must be followed by four hexadecimal digits. Uppercase U, x and ordinary letters such as m are not additional options. Copying a string from another language's source file can bring across escape syntax that its compiler accepts but a JSON decoder rejects.

An error involving a raw tab or newline has a different cause: the control character was put directly into the text, rather than represented by a valid escape. The page onbad control charactersexplains that case. A string ending just after a backslash may instead have been cut off, leaving the parser without a complete escape or a closing quote. Examine the surrounding characters before adding slashes throughout an unfamiliar document.

Regular expressions need the same treatment

A regular expression often contains backslashes with meanings of its own, such as a backslash followed by d for a digit. JSON does not know those meanings and rejects that combination as an escape. Store the expression as a JSON string with doubled backslashes, then let the regular expression engine interpret the decoded value. JSON has no literal regular expression type, so copying the surrounding slash delimiters from JavaScript source does not create a JSON value either.

{"pattern": "\\d+\\.\\d+"}

Be clear about which layer you are editing. A plain JSON file needs the doubled spelling shown above, but a JSON document embedded in a JavaScript source string also passes through JavaScript's string reader first. That extra layer can consume a backslash before the JSON parser even sees it. Inspect the actual text passed to the decoder, or construct an object and use JSON.stringify to encode it instead of manually counting escapes across several layers.

Finding the offending pair

Chrome's position 13 is the capital U, at line 1, column 14. Firefox points to that same letter, and Safari includes it in the words Invalid escape character U without an offset. Python reports column 13, char 12, pointing back to the backslash that opened the bad escape. This site's parser also starts its underline at that backslash. When comparing reports, look at the pair rather than assuming a one-column difference means the decoders found separate mistakes.

Older V8 in Node.js 18 called the U an unexpected token instead of naming the escape problem. The later wording in Chrome and Node.js makes the missing doubling easier to recognise, but both reject this exact input. Search results quoting either version can therefore describe the same Windows-path mistake, even when their wording differs from your console.

What Repair does with a stray backslash

The JSON Validator lets you inspect the offending escape in Code view. In this example,Repair doubles both backslashes and produces{"path": "C:\\Users\\me"}, which decodes to the path you typed. It does this for any backslash that no JSON escape begins with, such as the one before a capital U or before the d of a digit class, because nobody writes those on purpose to mean a bare letter.

Repair cannot rescue every path, though. A folder callednew or temp begins with a letter that is a JSON escape, so a backslash in front of it is already valid: it becomes a line break or a tab, and no decoder complains. That is how a hand-typed Windows path can load without an error and still point somewhere that does not exist. Repair leaves such pairs alone, since it has no way to tell them from an intended line break. ReadFix invalid JSONfor the broader workflow of checking each change before using repaired data in another program.