Why is my JSON invalid? The seven real causes

Almost every invalid JSON file breaks one of seven rules: a trailing comma, a missing comma, wrong quotes, an unquoted key, a comment, a wrong bracket, or a number written the wrong way.

Published

A parser rejects a document for a shorter list of reasons than most people expect. JSON’s grammar fits on a postcard, so there are only so many ways to break it. Here are the seven that account for nearly every failure, in the order you are likely to meet them.

1. The trailing comma

The single most common error in hand-edited JSON, almost always left behind after deleting a line:

{
  "name": "Sam",
  "email": "[email protected]",
}

A comma may only appear between items, never after the last one. Delete the comma after "[email protected]" and the document parses. Trailing commas are legal in JavaScript and Python, which is exactly why fingers keep producing them.

2. The missing comma

The mirror image, produced when a line is added in a hurry:

{
  "name": "Sam"
  "email": "[email protected]"
}

JSON has no line continuation — a newline means nothing. The parser sees "Sam" "email" and stops. Put a comma after "Sam".

3. Wrong quotes

JSON strings use straight double quotes, and nothing else. These all fail:

{'name': 'Sam'}      single quotes — Python/Ruby style
{“name”: “Sam”}      typographic quotes — a word processor or a rendered chat reply

Single quotes usually mean the JSON was produced by a Python print() of a dict rather than json.dumps(). Typographic quotes mean the text went through a word processor or was copied out of a rendered page instead of a code block. The fix is the same in both cases: straight double quotes.

4. The unquoted key

{name: "Sam"}

JSON is a serialization format — an exchange format for machines — and a bare word is ambiguous to a machine. Keys are strings, and strings are quoted. Write {"name": "Sam"}.

5. A comment

{
  // the port to listen on
  "port": 8080
}

JSON has no comments, and this is deliberate: a data format whose text can say two things at once (structure and commentary) cannot round-trip. Files like tsconfig.json extend JSON with comments and are properly called JSONC; strict parsers reject them. If you need notes, either use JSONC knowingly or keep a separate README.

6. The mismatched bracket

{"users": ["sam", "ada"]}

This one is legal — but its broken forms are everywhere: an object closed with ], an array closed with }, a missing closing bracket entirely (the classic truncated download or copy that stopped halfway). Count your brackets: every { needs a } and every [ needs a ], in the right order.

7. A number written the wrong way

JSON numbers are decimal only, with no leading zeros, no plus signs, and digits on both sides of the decimal point:

{"a": 01}        leading zero
{"a": +1}        plus sign
{"a": .5}        missing leading digit
{"a": 5.}       missing trailing digit
{"a": 0x1F}     hexadecimal
{"a": Infinity} not a number in JSON
{"a": NaN}      same

One more, subtler than the rest: a document can parse everywhere and still be wrong on numbers. An integer longer than about 15–16 digits, like 1234567890123456789, exceeds what a JavaScript number can represent exactly, and most JSON tools round it silently. The document is valid JSON; the tool is the thing lying. The validator on this site keeps such integers exact and tells you when you have one.

Finding which one you have

Paste the document into the JSON validator and it names the first thing that breaks, with the line, column, and the specific fix — in plain language, not a parser string. Anything in the list above that can be fixed mechanically gets a Fix it button, and the repair tool handles the whole batch, including stripped code fences if the JSON came out of a chat reply.