Who Invented JSON? The Douglas Crockford Story

The Pre-JSON Problem

In the late 1990s and early 2000s, web applications needed a way to exchange data between a browser and a server without reloading the entire page. This was before AJAX was named, before XMLHttpRequest was widely understood, and before anyone had formalised the concept of the single-page application.

The dominant data format of the time was XML — verbose, hierarchical, and requiring a parser to read. XML was designed for document markup, not for structured data exchange, but it was the tool available. Early web applications exchanged XML between client and server, parsed it on both ends, and used it to update parts of the page without full reloads. It worked, but it was cumbersome.

Douglas Crockford and the Discovery of JSON

Douglas Crockford, a software architect then working at State Software (later at Yahoo!), describes himself not as the inventor of JSON but as the person who discovered it. In his "JSON Saga" presentation, he explains that JSON was not invented from scratch — it emerged from the observation that JavaScript's object literal syntax, already present in the language since Netscape introduced JavaScript in 1995, could serve as a useful data interchange format.

Around 2001, Crockford and colleagues at State Software were building web applications that needed to pass data between browser and server. They realised that JavaScript object literals — the { key: value } syntax already embedded in every browser's JavaScript interpreter — could be sent from the server as a string, then evaluated in the browser using JavaScript's eval() function to produce a JavaScript object with no parsing overhead.

The key insight was that the JavaScript interpreter in the browser was itself a JSON parser — you just had to send valid JavaScript object literals and let the browser execute them. No XML parser library needed; no external dependency; no custom format. The format was already there, already understood by every JavaScript runtime in existence.

Formalising JSON: json.org (2001)

Crockford registered json.org in 2001 and published a formal specification of the format. The specification defined JSON as a strict subset of JavaScript object literal syntax — removing the parts of JavaScript that would allow arbitrary code execution when evaluated, keeping only the data structure and literal value syntax.

The critical restriction: JSON values can only be strings, numbers, booleans, null, arrays, and objects. No functions, no undefined, no date objects. This restriction made JSON safe to evaluate (it cannot execute arbitrary code) and simple to implement parsers for.

The json.org specification was deliberately minimal — the entire specification fits on a single page, famously illustrated with railroad diagrams showing the grammar. This minimalism was intentional and became a feature: JSON is simple enough that implementing a parser from scratch takes hours rather than weeks.

The Naming Fight: Is It Crockford's Invention?

Crockford has acknowledged that he was not the first to use this approach. Chip Morningstar, at Electric Communities in 1996, had used JavaScript object literals to communicate between browser and server. The approach was "in the air" among JavaScript-using web developers before Crockford formalised it.

What Crockford did that Morningstar and others had not was:

1. Give the format a name (JSON)
2. Write a formal specification
3. Create the json.org website to publish and evangelise the spec
4. Write implementations in multiple languages
5. Systematically campaign for its adoption

Invention versus formalisation is a distinction that matters less in practice than the credit Crockford deserves for turning an informal practice into a global standard. The format existed informally; Crockford made it official, named it, and created the infrastructure for adoption.

AJAX and the JSON Breakthrough (2004–2006)

JSON adoption accelerated with the naming and popularisation of AJAX (Asynchronous JavaScript and XML) by Jesse James Garrett in 2005. Despite "XML" being in the name, AJAX techniques could use any data format — and developers quickly found that JSON was far more convenient than XML for browser-side consumption. JSON strings, when evaluated, produced native JavaScript objects that could be navigated with dot notation and bracket notation immediately. XML required parsing, tree traversal, and namespace handling.

The progression was rapid: by 2006, JSON was in widespread use; by 2008, it was the preferred format for REST APIs; by 2013, it had arguably surpassed XML in API usage. The introduction of JSON.parse() and JSON.stringify() as native browser methods (replacing the risky eval() approach) in ECMAScript 5 (2009) completed the transition to a safe, efficient, native format.

Standardisation: RFC 4627, 7159, and 8259

JSON has been standardised through the IETF (Internet Engineering Task Force):

• RFC 4627 (2006) — the first official IETF JSON specification, authored by Crockford
• RFC 7159 (2014) — revised specification, clarifying ambiguities in the original
• RFC 8259 (2017) — current standard, authored by Tim Bray, making JSON a proper internet standard (STD 90)

JSON is also standardised by ECMA International as ECMA-404. The two standards are coordinated to remain consistent.

Crockford's Other Contributions

Douglas Crockford is better known in some circles for his 2008 book JavaScript: The Good Parts, which identified the subset of JavaScript that was well-designed and worth using — and helped establish the discipline of JavaScript programming as a serious engineering practice. His influence on JavaScript culture extends well beyond JSON.

Crockford also originated JSLint (a JavaScript code quality tool) and has been a consistent voice for careful, principled language design. His work on JSON stands as a model of the value of simplicity: the format's success owes more to what was left out than to what was put in.

Format your JSON →