How to fix a
JSON parse error.

The three messages, and what each one means

A JSON parse error reads like a complaint about the file rather than a pointer to the problem. It is not: each of the three messages comes with a line and a column, and the column points at the character where the parser gave up. We ran nine broken files through our own validator to get the exact wording:

Read that table as three families:

• “Expected a property name in double quotes” — the parser was at a position where a key should start. Either the key has no double quotes around it, or there is a comma where a key should be (a trailing comma), or there is a comment. Four of our nine test files produced this same message.
• “Expected a comma or a closing brace” — the parser finished a value and expected either a comma or the end of the object. A missing comma between two members lands here, and so does an object you forgot to close.
• “Expected an object, array, string, number, true, false or null” — a value was expected and something else was there. NaN, undefined and function calls are the usual culprits; a trailing comma in an array produces the same message.

The five-second check, in order

Almost every broken JSON file that arrives from a human is broken in one of five ways. In the order worth checking:

1. Trailing comma. {"a": 1,} is invalid JSON. Most programming languages accept it, which is why it survives so long. The error points at the line after the one with the comma, which is the first thing that confuses people — the comma is on line 3, the error says line 4.
2. Quotes that are not double quotes. JSON only accepts ". Not ', not «, and not the smart quotes that Word and Google Docs insert when you paste text into them: “a” is not "a", and the difference is invisible until something breaks.
3. A key without quotes. {a: 1} is a JavaScript object literal, not JSON. Every key needs double quotes.
4. Comments. JSON has no comment syntax at all. // and /* */ are rejected.
5. An unclosed bracket. A missing } at the end, or a missing ] inside an array. The error usually lands on the last line of the file, which points at the symptom rather than the cause.

One more that is not in the list because it has its own message: a bare value that is not valid JSON. NaN, Infinity and undefined are not JSON values. Use null for a missing number.

How to read the line and column

The column number is the character position the parser stopped at, counted from 1. In our test, a key without quotes on line 2 was reported at line 2, column 3 — the key starts there, and the parser was expecting a quote instead.

So the workflow is: look at the line, count to the column, and read the character just before it. In most cases the problem is that character, or the one right after it.

Our JSON validator does this for you and adds a jump to the error button, so you do not have to count characters by hand. It runs entirely in your browser: the JSON never leaves the page.

What it does not check

JSON has two separate questions, and it is worth being clear about which one a validator answers:

• Is this well-formed? Brackets, commas, quotes, valid value types. That is what a parse error is about, and that is what the validator checks.
• Is this the right shape? That is a schema question: whether age is a number rather than the string "twenty", whether a required field is missing, whether an enum value is one of the allowed ones.

The validator answers the first question. A file can be perfectly valid JSON and still be wrong for your API — which is the difference between a parse error and a 422 from a server. If you are chasing a schema problem, you need a schema, not a formatter.

When it parses, the useful part starts

Once the file is valid, the tool formats it: two-space indentation, in the order the keys were written. It also tells you what it parsed — object with how many properties, array with how many items — which is a fast way to catch the case where the API expects a list and you sent an object.

And formatting is worth doing before you paste JSON into a terminal, a shell script or a config file, because a single-line JSON blob is unreadable when something goes wrong at 2 a.m.

The limits, plainly

• It checks syntax, not schema. Valid JSON can still be the wrong shape for your API.
• It does not guess your intent. If a key is misspelled but well-formed, the validator is happy; only a schema would complain.
• JSON5, JSONC and NDJSON are not JSON. Comments, trailing commas and unquoted keys are all valid in those dialects and invalid here.
• Big files are slow to read in a tab. A multi-megabyte file in a textarea is not a pleasant experience; for very large payloads, validate them in your build pipeline instead.