When JSON Was Invented and Who Invented It

JSON is everywhere: API responses,

package.json

In reality, JSON was formalized in the early 2000s. Douglas Crockford is widely credited because he named it, documented a safe subset of JavaScript syntax for data, and pushed it into mainstream adoption.

JSON timeline (quick overview)

• 2001 to 2002: Crockford documents and popularizes JSON via json.org
• 2006: RFC 4627 publishes an early internet standard for JSON
• 2013: ECMA-404 defines a formal, language independent JSON grammar
• 2017: RFC 8259 becomes the widely cited modern specification

How JSON Came to Exist

Understanding JSON creation requires remembering early millennium web development landscape.

Internet growing fast. Web applications becoming more complex. Developers needed reliable methods for sending structured data between browsers and servers.

The Problem JSON Solved

Late 1990s and early 2000s: XML dominated data interchange format.

Worked but presented issues. Verbose and heavy. Simple data like user's name and age required opening and closing tags for every field. Browser XML parsing slow and cumbersome.

At the same time, JavaScript developers discovered a simpler approach. Instead of building XML and parsing it, they could represent data using JavaScript object and array literal syntax and evaluate it in the browser.

var user = { "name": "Alice", "age": 25, "active": true };

This avoided XML tags and extra parsing work. The browser’s JavaScript engine could interpret it natively because it was already valid JavaScript.

The catch was standardization. It was an ad hoc technique with no official specification, no widely accepted name, and no guarantee that different implementations would behave the same way.

Crockford Connects the Dots

Douglas Crockford worked at State Software around 2001. Building web applications requiring data exchange between server and browser.

He and colleagues used JavaScript-literal trick extensively. Realized it deserved recognition as proper data format.

Crockford’s contribution was straightforward in hindsight, but it mattered. He took a safe subset of JavaScript’s literal syntax for data representation, stripped out anything that could execute code, wrote down the grammar rules, and named it JSON (JavaScript Object Notation).

He registered json.org and published a concise description of the grammar, allowed data types (objects, arrays, strings, numbers, booleans, and null), and the syntax rules. For years, that page served as the de facto reference thousands of developers relied on.

Who Is Douglas Crockford

Crockford represents programming world figures with outsized software development influence. Not household name outside tech circles.

His Background

Before JSON, Crockford already deeply involved in JavaScript and web technologies.

Worked at various companies building interactive web systems. Time when JavaScript often dismissed as "toy language" not suitable for serious software engineering.

Crockford took JavaScript seriously earlier than most. He saw its potential and spent years focusing on its strengths and weaknesses.

He wrote "JavaScript: The Good Parts", a short but influential book that helped a generation of developers treat JavaScript as a serious language.

He also created JSLint, one of the earliest static analysis tools for JavaScript. It enforced a stricter subset and caught common mistakes before they became runtime bugs. Crockford described it as a tool that "will hurt your feelings", but it raised the bar for code quality on teams that adopted it.

Why He Created JSON

Crockford's motivation was practical, not academic. He needed a better way to move data between browsers and servers. XML worked but added friction that slowed down development. Manual string parsing was error-prone and tedious.

The JavaScript literal syntax was already being used informally for this purpose, but it needed a few things to become a real standard:

• A clear specification that different implementations could follow
• A name people could use to talk about the format
• Advocacy to convince the broader developer community (including server side languages) that it was not just a JavaScript trick

Crockford provided all three, which is why he is credited with inventing JSON even though the underlying syntax already existed in JavaScript.

How He Spread the Word

Crockford didn't take out ads or launch a marketing campaign. He published clear documentation on json.org, gave talks at conferences and companies, and consistently made the case that JSON was simpler and faster than XML for the common case of sending structured data over HTTP.

He also provided working implementations. Having parsers and serializers available in multiple languages meant developers could actually use JSON immediately rather than writing their own from scratch. This lowered the barrier to adoption dramatically.

One often-cited detail: the json.org specification is famously short. The entire format can be described in a few paragraphs with a handful of grammar diagrams. That brevity wasn't accidental. Crockford deliberately kept JSON minimal. There are no comments, no trailing commas, no optional features. Everything is mandatory and unambiguous. This made it easy to implement correctly and hard to implement differently from someone else.

The Timeline: From Informal Trick to Global Standard

JSON didn't become ubiquitous overnight. Its adoption followed a clear trajectory over about 15 years.

2000 to 2002: The Early Days

JavaScript developers were already passing data around using object and array literal syntax. Crockford and his team at State Software were among the first to recognize this as a distinct data format rather than just a coding pattern.

Around 2001, Crockford started documenting the format and sharing it with colleagues. By 2002, he had published the specification on json.org and coined the name "JavaScript Object Notation." The early spec was simple: it defined six data types, laid out the grammar, and that was it.

At this point, almost nobody outside of a small circle of web developers had heard of JSON. XML was still the unquestioned standard for data interchange.

2003 to 2005: AJAX Changes Everything

The mid-2000s brought a wave of interactive web applications that relied heavily on asynchronous communication between the browser and server. Google Maps, Gmail, and similar apps demonstrated that web pages could update dynamically without full page reloads. This pattern became known as AJAX (Asynchronous JavaScript and XML), and despite the "XML" in the name, many of these applications were actually using JSON under the hood.

JSON was a natural fit for AJAX because browsers could parse it instantly using JavaScript's built-in capabilities. XML parsing in the browser was comparatively painful, requiring DOM manipulation just to extract values. As AJAX-style development became mainstream, JSON adoption accelerated rapidly.

2006 to 2010: Libraries and Frameworks Jump On Board

Once AJAX popularized the pattern, server-side languages started adding JSON support. Python added the

json

json_encode()

json_decode()

This was a critical tipping point. JSON was no longer just a browser-side convenience. It was a genuinely cross-platform format that could replace XML in most API scenarios. REST APIs began defaulting to JSON instead of XML, and that shift accelerated year after year.

The IETF published RFC 4627 in 2006, which formally described JSON and registered the

application/json

2013 to 2017: Official Standardization

ECMA published ECMA-404 in 2013, providing a formal, language-independent specification of JSON's grammar. It was deliberately minimal, covering just the syntax rules without prescribing APIs or implementation details.

In 2017, the IETF published RFC 8259, which expanded on the earlier RFC with clearer guidance on character encoding (UTF-8 as the mandatory default), number handling, and interoperability requirements. RFC 8259 is considered the current authoritative specification for JSON.

Between these two standards, JSON went from a de facto standard (everyone uses it, but there's no official spec) to a proper international standard with clear rules that implementations can be tested against.

2017 to Present: Ubiquity

By this point, JSON had won. It's the default format for REST APIs, GraphQL responses, NoSQL databases, configuration files, message queues, logging systems, and countless other use cases. The ecosystem around it continues to grow with tools like JSON Schema for validation, JSON Patch for applying changes, JSON-LD for linked data, and JSON5 for a more human-friendly variant that supports comments and trailing commas.

JSON vs. XML: What Made JSON Win

Understanding why JSON overtook XML helps explain why it was invented in the first place.

Simplicity

A JSON object representing a person with a name and age looks like this:

{
  "name": "Alice",
  "age": 25
}

The same data in XML:

<person>
  <name>Alice</name>
  <age>25</age>
</person>

JSON uses fewer characters, has less visual noise, and maps more directly to the data structures developers work with in code. For the vast majority of API use cases, JSON's structure is all you need.

Parsing Speed

JSON parsers are simple and fast. The format has only six data types and a straightforward grammar. XML parsers have to deal with tags, attributes, namespaces, CDATA sections, processing instructions, entity references, and more. This complexity translates to slower parsing and higher memory usage.

Developer Experience

Working with JSON in code feels natural. You parse it and get back a dictionary or map with the keys and values right there. Working with XML typically requires navigating a DOM tree, querying with XPath, or processing SAX events. The friction is higher.

Where XML Still Wins

Despite all of that, XML isn't going away. It has genuine advantages in scenarios that require strict schema validation (XSD), document-centric data with mixed content, namespace management for combining multiple schemas, and existing enterprise integrations that would be costly to migrate.

XML is the better choice for some problems. But for the everyday task of "send some structured data from point A to point B over HTTP," JSON is simpler, faster, and more pleasant to work with.

How JSON Evolved After Its Creation

JSON's core syntax hasn't changed since Crockford defined it. The six data types, the grammar rules, and the structural conventions are the same today as they were in 2002. That stability is a feature, not a limitation. It means code written to parse JSON a decade ago still works perfectly.

What has evolved is the ecosystem around JSON.

JSON Schema provides a way to validate JSON documents against defined rules, similar to what XSD does for XML. It's widely used in API documentation (OpenAPI/Swagger relies on it) and form validation.

JSON-LD extends JSON with conventions for representing linked data, making it possible to embed semantic web information in standard JSON structures. You'll encounter it in SEO (structured data markup uses JSON-LD) and knowledge graph applications.

JSON5 is a superset of JSON that adds quality-of-life features developers have been requesting for years: comments, trailing commas, single-quoted strings, multiline strings, and hexadecimal numbers. It's popular for configuration files where JSON's strictness is annoying.

BSON (Binary JSON) is used by MongoDB to store JSON-like documents in a binary format that's more efficient for storage and querying. It adds data types that JSON lacks, like dates and binary data.

The Standardization Process in Detail

JSON has two complementary official standards, and understanding the difference helps if you ever need to reference the spec.

ECMA-404

Published by ECMA International in 2013, ECMA-404 is the canonical definition of JSON's grammar. It's intentionally brief and focused. It defines the six data types, the syntax rules, and nothing else. No recommended APIs, no encoding requirements, no implementation guidance. The philosophy is: define the format precisely and leave everything else to implementers.

ECMA-404 is the standard you'd reference if you were building a JSON parser from scratch. It tells you exactly what constitutes valid JSON.

RFC 8259

Published by the IETF in 2017 (superseding the earlier RFC 4627 and RFC 7159), RFC 8259 takes a more practical approach. It includes the same grammar as ECMA-404 but adds guidance for using JSON in internet protocols: UTF-8 as the required encoding for JSON exchanged over networks, recommendations for handling edge cases like duplicate keys, and the

application/json

RFC 8259 is the standard you'd reference when designing an API or protocol that uses JSON. It tells you how to use JSON correctly in networked systems.

JSON's Impact on Modern Development

It's hard to overstate how much JSON changed the developer experience for building web applications.

The AJAX Revolution

Before JSON, getting data from a server to a browser was cumbersome. You'd make an XMLHttpRequest, get back an XML document, navigate the DOM tree to extract values, and convert them to JavaScript variables. With JSON, you make a request, call

JSON.parse()

response.json()

That simplification didn't just save developers time. It lowered the barrier to building interactive web applications. Developers who might have struggled with XML parsing could easily work with JSON, which accelerated the entire AJAX movement.

APIs Became Easier to Build and Consume

The REST + JSON combination became the standard architecture for web APIs because both sides are simple. Server-side frameworks serialize objects to JSON with one function call. Client-side code parses the response just as easily. The format's transparency (you can read a JSON response and understand it immediately) also made API debugging much more approachable.

Configuration Got Standardized

JSON's adoption as a configuration format (package.json, tsconfig.json, .babelrc) gave the JavaScript ecosystem a consistent way to define project settings. Before that, every tool had its own config format. Standardizing on JSON (and later, its more permissive cousin JSON5) reduced cognitive overhead for developers working across multiple tools.

NoSQL Databases Emerged

MongoDB, CouchDB, and other document databases store data in JSON like formats. The idea of storing documents rather than rows in tables was partly enabled by JSON’s flexibility. A MongoDB document is essentially a JSON object with some additional types. This made the leap from "data an API returns" to "data a database stores" almost seamless.

Frequently Asked Questions

When exactly was JSON invented?

JSON was formalized between 2001 and 2002 by Douglas Crockford. He published the specification on json.org in 2002 and registered the domain that same year. The underlying JavaScript syntax it's based on had been in use informally before that.

Did Douglas Crockford invent JSON from scratch?

Not exactly. He identified a pattern that JavaScript developers were already using (object and array literal syntax for data interchange), formalized it into a specification, named it, and advocated for its adoption. The syntax came from JavaScript. The standardization and promotion came from Crockford.

Why is it called JavaScript Object Notation if it's language-independent?

The name reflects JSON's origins in JavaScript syntax. The format uses the same notation as JavaScript objects and arrays. However, JSON is entirely language-independent. Every major programming language has JSON support, and you don't need JavaScript to work with it.

When did JSON become an official standard?

ECMA-404 was published in 2013, and RFC 8259 was published in 2017. Before that, JSON was a de facto standard based on Crockford's specification on json.org. The earlier RFC 4627 from 2006 was the first IETF document to describe JSON.

How did JSON overtake XML?

Gradually, and then all at once. The AJAX movement in the mid-2000s showed that JSON was faster and simpler for web data exchange. As REST APIs replaced SOAP services and JavaScript frameworks grew in popularity, JSON became the default. XML remains relevant in enterprise contexts, but for web APIs, JSON won decisively.

What was used before JSON?

XML was the primary data interchange format, particularly through SOAP web services. Some applications used custom text formats, CSV, or proprietary binary protocols. JSON offered a middle ground: simpler than XML but more structured than plain text.

Wrapping Up

JSON's story is ultimately about a developer who paid attention to what other developers were already doing, documented it clearly, and championed it until the rest of the world caught up. Douglas Crockford didn't invent a revolutionary new technology. He recognized a practical pattern, gave it a name and a spec, and made it easy for everyone to adopt.

That's why JSON is everywhere today. It wasn't designed by a committee or mandated by a standards body. It grew organically from real developer needs and was polished into a standard by someone who understood that simplicity is a feature, not a limitation. Twenty-plus years later, JSON's core format hasn't changed at all, and that's probably the strongest endorsement of its original design.

Related Resources

• Deep dive into how JSON works internally
• Understand how JSON powers everything on the web
• Compare JSON vs XML vs YAML formats
• Work with JSON using the JSON tools for merging, splitting, and converting