JSON: how a JavaScript accident won the data wars
Why JSON beat XML everywhere, the five syntax rules that cause every validation error, and where it genuinely falls short.
5 min read · Reviewed July 2026
JSON wasn't designed by a committee — it was discovered inside JavaScript. Douglas Crockford noticed in the early 2000s that JavaScript's object literal syntax was already a decent data format: readable by humans, parseable by machines, no schema ceremony required. He wrote it down on one page. That one page beat XML, an entire industry of schemas, namespaces, and validators, essentially everywhere.
It won for one reason: it's minimal. Objects in braces, arrays in brackets, strings in double quotes, numbers, true/false/null. That's the whole language. XML made you decide whether data belonged in attributes or elements; JSON removed the decision.
The five rules everyone breaks
Every 'invalid JSON' error traces to a handful of rules JavaScript itself doesn't enforce, which is why hand-written JSON fails so often. Double quotes only — single quotes are invalid. Keys must be quoted. No trailing commas after the last item. No comments, anywhere (Crockford removed them deliberately, to stop people abusing them for parser directives). And no undefined — null is the only 'nothing'.
Paste a failing blob into the validator above and the error position almost always lands on one of those five. The formatter fixes none of them for you — it can't guess intent — but it makes the mistake visible in about a second.
Where JSON falls short
No comments hurts config files — which is why the ecosystem grew JSON5, JSONC, and YAML for that niche. No date type means every API invents its own timestamp convention (use ISO 8601 strings and move on). Big numbers silently lose precision because everything is a float — serialize 64-bit IDs as strings; every developer learns this from a corrupted ID eventually. None of these flaws threaten JSON's throne. Minimal beats complete, apparently forever.