How JSON quietly took over the web
Every API you touched today almost certainly spoke JSON. The format's origin is unusually modest: Douglas Crockford and colleagues popularized it in the early 2000s as a way to ship data between server and browser using nothing but JavaScript's own literal syntax — no plugins, no parsers to install. He has been clear that he "discovered" rather than invented it; the syntax was already sitting inside ECMAScript.
Standardized twice
JSON is small enough that its grammar fits on the back of a business card, and it is formally specified twice over: ECMA-404 defines the pure syntax, and the IETF's RFC 8259 defines its use as an interchange format (UTF-8, interoperability notes, security considerations). The famous railroad diagrams on json.org are still the friendliest specification any format ever had.
Why the strictness is a feature
Newcomers are surprised that JSON rejects things JavaScript happily accepts — single quotes, trailing commas, comments, unquoted keys. That rigidity is deliberate: a format with one canonical form is trivial to parse identically in every language, which is precisely what an interchange format must guarantee. The price is the occasional infuriating Unexpected token — which is what a JSON formatter and validator is for.
What it displaced, and what nibbles at it
JSON displaced XML for most API work by being lighter to read and native to the browser. Today, YAML owns configuration files (by being friendlier to humans and accepting comments), and binary formats like Protocol Buffers own high-performance internal traffic. But for public APIs, JSON's combination of human-readability, universal parser support and strict simplicity remains unbeaten — twenty years on, the business card still wins. If you work with data exports, our CSV to JSON converter bridges the spreadsheet world into it.