Douglas Crockford documented a data format that JavaScript already knew how to read, and it quietly displaced XML before most people had noticed the argument was over.
Crockford Didn't Invent It, He Named It
The story of JSON is the story of a man finding something that already existed and writing it down carefully. In the early 2000s, developers building early AJAX applications — before that acronym existed — were looking for ways to pass structured data between a server and a browser without a full page reload. XML was the official answer. It was verbose, required a parser, and demanded that the client navigate a document object model just to read a string out of a response.
Douglas Crockford, working on projects that involved server-to-browser communication around 2001, recognized that JavaScript's object literal syntax already described exactly what those exchanges needed. A JavaScript engine could evaluate a string like {"name":"value"} natively, because the syntax was already part of the language Brendan Eich had shipped in Netscape Navigator in 1995. Nothing new needed to be installed on either end. The server serialized; the browser parsed via eval(). Crockford registered json.org in 2002 and published a simple grammar and a description of the format. He later said — and has been consistent about this — that he did not invent JSON but rather discovered it within what JavaScript already was.
That distinction matters for the history. JSON's adoption was not a standards battle where one committee's proposal defeated another's. It was recognition of an arrangement that already functioned in deployed software.
Chronology
- 1995JavaScript shipped in Netscape Navigator, carrying the object literal syntax JSON would later formalize
- 2001–2002Crockford identifies and documents the pattern; json.org registered
- 2005Jesse James Garrett's Ajax essay gives the surrounding pattern its name
- July 2006RFC 4627 publishes JSON as a formal IETF specification
- 2009–2011
JSON.parse()/JSON.stringify()specified in ES5 and shipped across major browsers - 2014, 2017RFC 7159 and RFC 8259 refine but do not change the format
The Format That Needed No Permission
By the time Jesse James Garrett coined "Ajax" in a 2005 essay and gave the pattern its name, JSON was already circulating as an informal standard. The pattern it supported — lightweight data exchange without a plugin, without a dedicated parser, without XML schema negotiation — mapped almost perfectly onto what jQuery and its contemporaries needed to make cross-browser asynchronous requests tractable. When jQuery added $.getJSON() in its early versions, it was formalizing what developers had already been doing by hand.
The competition with XML was not really fought on technical grounds; it was resolved by activation energy. Using XML from a browser meant choosing a parser, understanding the DOM query interface for XML documents, and handling namespace edge cases that varied by browser. JSON needed none of that. An eval() call — later replaced by the safer JSON.parse() — was sufficient. That asymmetry was not a feature Crockford added; it was inherited from the host language.
The IETF published JSON's first formal specification as RFC 4627 in July 2006, which gave organizations that required a citable standard something to point at. That was enough. Enterprise adoption followed without JSON having to prove itself further. The later RFC 7159 in 2014 and RFC 8259 in 2017 refined the specification and clarified edge cases around encoding and number precision, but the format itself did not change in any way that broke existing implementations.
The thing it displaced
- XMLrequired a parser, a DOM query interface, namespace handling, and schema negotiation; none of these were already present in a JavaScript runtime
- The switch was not a standards vote; it was a difference in activation energy between two approaches
What It Rests On
JSON's apparent simplicity conceals a few decisions whose consequences took years to surface. Number representation, for instance, has no explicit precision constraint in the format — JSON has no distinction between an integer and a floating-point value, which means sufficiently large integers lose precision when passed through JavaScript's IEEE 754 doubles. This became a practical problem as systems began using large database identifiers in JSON APIs, and the common fix — serializing those identifiers as strings — is an informal convention rather than anything in the specification.
The eval() path JSON originally relied on was itself a security consideration: evaluating arbitrary server-supplied strings as JavaScript was obviously exploitable if the source was untrusted, which is why JSON.parse() — specified in ES5 and shipped in browsers from around 2009 to 2011 — was a meaningful safety improvement, not just a performance one. TC39's inclusion of JSON.parse() and JSON.stringify() in ES5 formalized what had been a landscape of competing library implementations, including Crockford's own reference code.
The broader lesson the JSON story carries is that the formats which win are rarely the most expressive. They are the ones that arrive with the lowest cost to begin using — and JSON had effectively zero, because the environment that would consume it had shipped the parser years earlier without meaning to.