Common JSON Errors and What the Error Messages Mean

When JSON fails to parse, the error message is the best clue you have, but each browser words it differently, and the position it reports is where the parser gave up, which is not always where the mistake is. To see what that looks like in practice, the same twelve broken snippets were run through JSON.parse in Chrome 153, Firefox 153 and WebKit 26.5 (the engine inside Safari). The messages below are copied exactly as each engine produced them.

The messages, side by side

Firefox's messages all start with JSON.parse: and end with of the JSON data; that wrapper is trimmed above. Safari's all start with JSON Parse error:.

Reading the position

Chrome reports two numbers. position 27 counts characters from zero; line 1 column 28 counts from one, and that is the pair your editor shows. Firefox gives only the line and column. Safari gives neither, and five different mistakes in the table produce the same Expected '}', so on a long payload Safari's message alone won't find the problem. Paste the JSON into the JSON Formatter in Chrome or Firefox: it shows the browser's own message, so you get the column.

The column is where the parser noticed something was wrong, which is often one step after the actual mistake:

• Trailing comma: column 28 is the closing }. The comma before it was fine until the parser found no key after it. Delete the comma, not the brace.
• Unescaped quote: column 22 is the h of hi. The quote before it closed the string early, so the parser expected a comma next. Write \"hi\" instead.
• Missing closing brace: column 15 is one past the end of the text. The parser ran out of input while still inside the outer object. On a large file, count braces around the last object you edited rather than looking at the end.

Fixing each kind of mistake

• Quotes. Keys and strings take double quotes, always. Safari is the only engine that names single quotes; Chrome and Firefox just say they expected a property name.
• Comments. JSON has none. If a config file needs them, it is really JSONC or JSON5, and the program reading it must use a parser for that format.
• JavaScript-only values. undefined, NaN and Infinity are valid JavaScript but not JSON. JSON.stringify turns NaN into null and drops keys whose value is undefined, so hand-written JSON is usually where these come from. Use null, or a string if the value must survive.
• Line breaks in strings. A real newline inside quotes is a control character. Write \n instead. This one appears when text is pasted into a JSON file from a document.
• Leading zeros. A JSON number can't start with 0 unless it is 0 itself or a decimal like 0.5. Codes such as PIN codes and account numbers belong in quotes, "004102", which also stops them being treated as quantities later.
• Empty input. Unexpected end of JSON input usually doesn't mean broken JSON at all: the text was empty. In code it most often comes from calling response.json() on an HTTP response with no body, such as a 204 No Content. Check response.status, or read response.text() first and parse only if it isn't empty.

Once it parses

Valid JSON can still surprise you when a formatter rewrites it, because formatting parses and re-serializes the data. The JSON Formatter page lists the cases where the output differs from what you pasted, such as very long integers. If the JSON is headed for a spreadsheet next, the JSON to Excel, CSV, XML and YAML guide covers what changes in each format.