10 Common JSON Errors and How to Fix Each One
Trailing commas, single quotes, comments, unquoted keys, raw line breaks and more: ten mistakes that make JSON.parse fail, with a bad and good snippet for each and the error you will see.
Why JSON fails when it looks fine
JSON looks like a JavaScript object, so people write it the way they write JavaScript. That is where most errors come from. JSON is a much stricter format: a small fixed set of rules, no shortcuts, and a parser that stops at the first character it does not accept. The JSON formatter and the JSON minifier both hand your text to the browser's built-in JSON.parse(). If it parses, you get output. If not, you get the parser's own error message, and nothing else.
Two things to know before the list. First, the wording of the message depends on your browser. The examples below show the style used by current Chrome-based browsers, which names what it expected and gives a position; Firefox and Safari phrase the same problems differently, but the position it points to is usually the same place. Second, the parser reports where it noticed the problem, which is sometimes one token after the real mistake. When the position looks wrong, look just before it.
Errors 1 to 4: syntax borrowed from JavaScript
1. Trailing comma
Bad: {"a":1,}
Good: {"a":1}
The parser reports something like "Expected double-quoted property name ... at position 7": after the comma it was waiting for another key and found a closing brace. The same applies to arrays: [1,2,] is invalid. This usually happens when you delete the last item of a list and leave the comma behind. Remove the comma after the final element.
2. Single quotes
Bad: {'name':'Ana'}
Good: {"name":"Ana"}
JSON allows only double quotes, for both keys and string values. The error points at position 1, the first single quote, with a message such as "Expected property name or '}'". If you are building JSON by hand in a script, let a serializer do the quoting instead of concatenating strings.
3. Unquoted keys
Bad: {name: "Ana"}
Good: {"name": "Ana"}
This produces the same style of error as single quotes, at the first character of the key. Object literals copied out of JavaScript source or a browser console are the usual origin. Wrap every key in double quotes.
4. Comments
Bad: {"a":1 // retry count }
Good: {"a":1}
JSON has no comment syntax at all, neither // nor /* */. The parser sees the slash where it expected a comma or a closing brace and stops. Delete the comments before parsing. If you need notes in a configuration file, check whether the program reading it accepts a commented variant such as JSONC; plain JSON.parse() does not, and neither do our tools. Another common workaround is a dedicated key such as "_comment", which is valid JSON, though your application will receive it as ordinary data.
Errors 5 to 7: values that JSON does not define
5. Missing comma between items
Bad: {"a":1 "b":2}
Good: {"a":1,"b":2}
The message is "Expected ',' or '}' after property value" at the start of the second key. It happens when you paste a new line into the middle of an existing object. Because the position is the start of "b", the missing comma is just before it.
6. undefined, NaN and Infinity
Bad: {"a":undefined} or {"a":NaN}
Good: {"a":null}
JSON's only non-string, non-number, non-boolean value is null. The parser reports an unexpected token at the first letter, such as 'u' or 'N'. The usual source is a program that printed its own values with string formatting rather than a JSON serializer. Decide what the missing value should mean in your data, and write null, omit the key, or use a string.
7. Numbers written the wrong way
Bad: {"a":007}, {"a":+1}, {"a":.5}, {"a":0x1F}
Good: {"a":7}, {"a":1}, {"a":0.5}, {"a":31}
JSON numbers are decimal only. They cannot start with a plus sign, cannot have leading zeros, must have a digit before a decimal point, and have no hexadecimal form. Codes that must keep leading zeros, such as a PIN code or a phone number, belong in strings: "pin":"011000".
Errors 8 to 10: text that is not really JSON
8. Raw line breaks inside a string
Bad: a string value that continues onto a second line in the source text.
Good: {"a":"line1\nline2"}, where \n is the two characters backslash and n.
Control characters, including a real newline or tab, are not allowed inside a string. The message is "Bad control character in string literal". Multi-line text has to be written with escape sequences. If you copy a long address or paragraph from a spreadsheet cell into a JSON value, this is the error you will meet.
9. Extra text around the JSON
Bad: {"a":1} extra
Good: {"a":1}
The parser reads one complete value and then complains about "non-whitespace character after JSON". Typical causes are a log prefix or suffix copied along with the payload, two JSON objects pasted back to back, or a stray closing bracket. Keep only one value. If you have many records, wrap them in a single array. An empty input produces "Unexpected end of JSON input", and so does truncated text such as {"a":[1,2, which is why a half-copied API response fails.
10. JSON that is wrapped in a string
Bad: "{\"a\":1}"
This one is sneaky because it is valid. The whole text is a single JSON string whose content happens to look like an object. The formatter will accept it and print the same quoted string with escapes, and you will not see the structure you expected. It appears when a field was serialized twice, or when you copied a value out of a log that shows the escaped form. Remove the outer quotes and the backslashes before the inner quotes, or parse it twice in your code.
Errors that do not raise an error
Some problems parse successfully and still change your data. They matter more than the loud failures, because nothing warns you.
| Input | What the tool outputs | What happened |
|---|---|---|
{"a":1,"a":2} | {"a":2} | Duplicate key: the last value wins and the first disappears. |
{"id":9007199254740993} | {"id":9007199254740992} | Integers beyond 9,007,199,254,740,991 are rounded. |
{"id":12345678901234567890} | {"id":12345678901234567000} | The last digits are replaced with zeros. |
{"b":1,"10":2,"2":3} | {"2":3,"10":2,"b":1} | Whole-number keys are moved to the front, in ascending order. |
If your data contains 64-bit identifiers, send them as strings from the start. Rounding happens when the text is parsed, so formatting it afterwards cannot restore the digits. For duplicate keys, look at where the document was produced; a tool that writes the same key twice usually has a bug that you will want to fix at the source.
A quick routine for hunting an error
- Paste the text into the JSON formatter and read the position in the message.
- Look at the character before that position first: a missing or extra comma is almost always there.
- If the text is long, cut it in half. Parse the first half wrapped appropriately and see whether the error moves.
- Once it formats cleanly, scan the output for the silent problems above: a value that is missing, a large number that ends in zeros, a key that moved.
- If you need to ship it compactly, run it through the JSON minifier afterwards. Valid JSON is the only input it accepts, so it also acts as a final check.
When the document is valid but large and you only need one field, the JSONPath tester lets you write an expression that starts with $ and see the matching values, which is quicker than scrolling a long file.
Limits: what these tools do not do
- They do not repair JSON. There is no auto-fix. On invalid input you get the parser's message and no formatted output, so you correct the text yourself.
- They check syntax only. A document can be valid JSON and still have the wrong field names, wrong types or missing required values for your application. There is no schema validation.
- They report one error at a time. The parser stops at the first problem, so a file with five mistakes needs several rounds.
- Error wording is the browser's. The message text can differ between browsers, and we do not rewrite it.
- They cannot recover lost precision. Large integers and duplicate keys are changed during parsing, before our code sees the result.
Parsing happens in your browser, so a pasted payload is not uploaded by these tools. It is still good practice to strip tokens, passwords and personal data before sharing formatted output with anyone else.