JSON earns its keep by being boring: a small grammar, no surprises, the same parse everywhere. The flip side is that the grammar is stricter than the JavaScript it resembles, so hand-written or hand-edited JSON fails in a handful of predictable ways. Almost every "invalid JSON" error you will ever meet is one of seven mistakes. Learn the seven, and you can write JSON that parses first time — and repair other people's payloads in minutes.
The seven rules
1. Every key is a double-quoted string. There are no unquoted keys in JSON and no single-quoted strings. If your source language prefers single quotes, the document still has to be converted before a strict parser will touch it.
2. No trailing commas. JavaScript tolerates a comma after the last item in an array or object; JSON does not. This is the single most common reason a hand-edited config file refuses to load — the comma looks harmless, so nobody suspects it.
3. Strings escape a fixed set of characters. A double quote inside a string is written \", a backslash as \\, and control characters such as newlines as \n — never typed literally. Text pasted out of logs and emails breaks here constantly.
4. Numbers have exactly one format. No leading plus sign, no leading zeros (0.5 is fine, 00.5 is not), no hexadecimal, and no bare NaN or Infinity — those are JavaScript values, not JSON. Scientific notation like 1.2e3 is allowed.
5. Only three literals exist: true, false, null — all lowercase. True, False, None and NULL belong to other languages. JSON is case-sensitive about its literals and parsers will not guess your intent.
6. There are no comments. Neither // nor /* */ exists in the grammar. If your config format needs annotations, you are looking for JSON5, JSONC or YAML — and a strict parser will fail on the very first comment it meets.
7. A document is one value, encoded as UTF-8. Exactly one top-level value: object, array, string, number, boolean or null. Two objects back to back is a JSON Lines stream, not a document, and stray text after the closing bracket — a log prefix, a mangled byte-order mark — invalidates everything.
When it still will not parse: debug from the error
Start where the parser stopped, not at the top of the file. A parser reports the first character it cannot make sense of, which means the actual mistake sits at that position or a few characters before it. Look backwards for the usual suspects: the comma after the previous item, the quote that should have closed the previous string, the bracket that never opened. A formatter that reports line and column turns this from a treasure hunt into a single glance.
Next, bisect. Delete half the payload and test what remains; two or three rounds of halving isolate any syntax error to a handful of lines, regardless of how large the original file was. It feels crude and it works every time.
One more validation trick for payloads you receive from other systems: parse, re-serialize and parse again. If the document survives the round trip unchanged in structure, it was well-formed; if a tool along the way "helpfully" repaired it, the difference between the two parses shows you exactly where the damage was.
Finally, adopt the habit that prevents most of these bugs: when your code produces JSON, produce it with a serializer, never by joining strings. Every hand-built JSON string is an escaping bug waiting for the one input that contains a quote.
Try the tool behind this article: JSON Formatter & Validator runs entirely in your browser — nothing you paste is uploaded.