JSON is the most successful data format of the past 25 years. Nearly every public API speaks it, every browser parses it natively, and every programming language has a library for it. But it almost didn't happen. Here's the short version of how a JavaScript subset became universal.

The XML era (1998–2002)

Before JSON, web services exchanged data in XML. The dominant standards were SOAP for RPC and XML-RPC for simpler cases. Both required schemas, namespaces, and verbose envelopes. A request to add two numbers might be 300 bytes of XML wrapping 20 bytes of actual data.

The pain was acute for browser developers. JavaScript could parse XML, but the DOM API was awkward and the resulting object graph never quite matched what you wanted. Most developers ended up calling eval() on JavaScript object literals returned from servers — which worked but was a security disaster.

The Crockford insight (2001)

Douglas Crockford, then at State Software, noticed that JavaScript already had a clean, minimal way to express structured data: object and array literals. If you restricted the syntax to a subset that contained no executable code — no functions, no variable references, no comments — you'd have a portable data format that any JavaScript engine could parse for free, just by reading the response into a variable.

Crockford registered json.org in 2002 and published the grammar on a single page. The entire spec fit in a diagram with eight states. That minimalism was the design.

The naming

The acronym "JSON" stands for JavaScript Object Notation, but the name is slightly misleading. JSON is not a subset of JavaScript in a strict sense — JSON allows some Unicode line terminators inside strings that JavaScript treats as syntax errors. ECMAScript 2019 fixed this incompatibility by relaxing JavaScript's rules to fully include JSON.

The deeper irony: JSON's most important property has nothing to do with JavaScript. It's that the format is small enough to specify completely on a postcard, and unambiguous enough that two independent parsers will always produce the same result.

The rise (2005–2010)

Three forces drove JSON's adoption past XML in the mid-2000s:

AJAX. Jesse James Garrett coined the term "AJAX" in 2005 to describe asynchronous browser requests. The original "X" stood for XML, but within a year most AJAX traffic was JSON because parsing was faster and the resulting objects were more natural to work with in JavaScript.

REST. Roy Fielding's REST architectural style, popularized through the mid-2000s, didn't require any particular format — but JSON's brevity made it the natural default for "REST-style" APIs. Twitter's first public API (2006) offered both XML and JSON; within two years almost everyone was using JSON.

NoSQL. MongoDB launched in 2009 storing data as BSON (a binary superset of JSON). CouchDB used JSON natively. The document-database wave normalized "your data is a JSON object" as a design pattern.

Standardization (2013–2017)

JSON was widely deployed before it was formally standardized. RFC 4627 (2006) was an informational document — not a standard. RFC 7159 (2014) and then RFC 8259 (2017) finally pinned down the ambiguities: encoding must be UTF-8, top-level values can be any JSON value (not just objects or arrays), duplicate keys are technically allowed but their behavior is unspecified.

ECMA-404 (2013, updated 2017) is the parallel ECMA standard. The two specs are now aligned.

JSON's competitors and offshoots

Several formats have tried to improve on JSON. JSONC and JSON5 add comments and trailing commas. YAML is a superset of JSON with human-friendly syntax. Protocol Buffers, MessagePack, and CBOR offer binary alternatives that are faster and smaller. Each has its niche, but none has displaced JSON as the lingua franca of public APIs.

The reason is path dependence: JSON is the default, every tool supports it, and the marginal benefit of switching rarely justifies the cost. Network is cheap; parser speed is rarely a bottleneck; human readability matters during debugging.

What's next

JSON itself probably won't change. The spec is frozen and that's a feature. What changes is the ecosystem around it: JSON Schema for validation, JSON Pointer (RFC 6901) for addressing, JSON Patch (RFC 6902) for diffs, and JSONPath for queries. These are layers built on top, each filling in a gap that the original spec deliberately left out.

Crockford's original goal was a format you could explain in five minutes and implement in a day. Twenty-five years later, that's still why it wins.