History

The origin of JSON: the story behind the format

JSON did not begin as a grand standard. It began as a practical answer to a small question: how can a browser and a server pass a structured message to each other without bringing an entire programming language along for the ride?

Before JSON, the web was learning to speak

In the late 1990s, web pages were becoming less like printed documents and more like applications. A page could ask a server for new data, update one part of the screen and keep the rest of the page in place. The browser and server needed a shared way to describe records, lists and small values.

XML was a serious answer. It could describe nested data, carried a large ecosystem of tools and was already familiar to many enterprise teams. It also asked a small browser message to carry opening tags, closing tags and a lot of punctuation. Developers wanted the structure, but often wanted to write less of it.

The clue was already inside JavaScript

JavaScript had a compact way to write an object or an array. A developer could describe a person like this:

JSON
{
  "name": "Ada",
  "roles": ["engineer", "writer"]
}

In a JavaScript program, that text could be an object literal. The same shape also worked well as plain data. It was easy for a browser to read, easy for a human to inspect and small enough to send over a connection. The important step was to treat the shape as a data notation rather than as JavaScript that a browser should execute.

That distinction explains many of JSON's rules. JSON uses double-quoted strings, a small set of value types and no functions. Comments, variables and expressions belong to a programming language. They do not belong in a portable data document.

Douglas Crockford gives the idea a name

Around 2000, Douglas Crockford and colleagues at State Software were working on browser and server messaging. They used a notation based on JavaScript object and array literals because it fit the job. The notation was not invented from nothing. Its punctuation had been part of JavaScript for years. The work was to recognize the useful subset, describe it clearly and give it a name people could share.

That name was JavaScript Object Notation, or JSON. JSON.org gave the format a public home in the early 2000s. The name pointed to its family resemblance to JavaScript while the format itself remained deliberately smaller than JavaScript. A JSON document could travel between languages without asking the receiving system to understand JavaScript code.

The first JSON was small on purpose

JSON describes six kinds of value: objects, arrays, strings, numbers, booleans and null. An object maps string names to values. An array keeps an ordered list of values. That is enough to represent most messages exchanged by a web application, and the rules are short enough to remember.

The small grammar also set a boundary. JSON numbers do not define a universal precision model, so languages must decide how to store very large or very exact numbers. JSON objects do not promise a meaningful order for their members. A parser may preserve the written order, but programs should not use that order as a hidden instruction.

Browsers turn a notation into a web habit

As XMLHttpRequest-style applications spread, JSON became a convenient payload for requests and responses. The pattern became familiar: the browser sent a small request, the server returned an object or array, and JavaScript used the result to update the page. The industry later gave this family of techniques a memorable name, Ajax.

JSON won space in that moment because it matched the browser's native vocabulary. It was shorter than many XML messages, fit naturally into JavaScript code and still had enough structure for other languages to parse. It was a useful compromise between human readability and machine processing.

From a shared convention to a written standard

For a while, JSON was mostly a convention described by its community. That changed when the format was written down in formal standards. RFC 4627, published in 2006, documented JSON and registered application/json as its media type. It described a top-level object or array as the complete JSON text.

ECMA-404 followed in 2013 with a language-independent description of the JSON syntax. The IETF later published RFC 7159 in 2014 and RFC 8259 in 2017. Those revisions clarified interoperability details and allowed any JSON value at the top level, so a standalone string, number, boolean or null could also be a JSON text. ISO/IEC 21778:2017 aligned with the same core format.

A format that left its first language behind

JSON's name kept the memory of JavaScript, but its audience became much larger. Python, Java, Ruby, Go, C#, PHP, Rust and many other languages gained JSON parsers and serializers. APIs adopted it because a client could be written in almost any language and still exchange the same basic structures.

JSON looks like JavaScript, but it is not JavaScript.

That is the quiet twist in the story. A JSON document cannot contain a function, a comment or an undefined value. A valid JSON document is data that a program can choose to turn into a native object, record or map. Keeping that boundary clear is what let JSON cross language borders.

The rules that still matter today

  • Object keys and strings use double quotes.
  • Values are separated with commas, with no trailing comma after the last member or item.
  • JSON spells the special values true, false and null in lowercase.
  • Whitespace can change the shape on screen, but it does not change the data.
  • Comments, NaN, Infinity and unquoted keys are outside standard JSON.
  • Different languages may handle number precision differently, especially for very large integers.

Why the origin story is useful

Knowing where JSON came from makes its design easier to read. The format is small because it was meant to carry messages, not behave like a full programming language. It resembles JavaScript because the browser was its first natural home, then it became independent enough to serve every language around it.

When a document fails validation, the error is usually a broken part of that small contract: a missing comma, a quote in the wrong place or a value JSON never defined. The Tool Kumar JSON viewer shows the line and column where the parser stops, formats valid input and can repair several common JSON-like mistakes while keeping the work in your browser.

A short timeline

  1. Late 1990sRicher browser applications create demand for compact structured messages.
  2. Around 2000Browser and server work at State Software uses a JSON-like notation based on JavaScript literals.
  3. Early 2000sJSON.org gives JavaScript Object Notation a public name and description.
  4. 2006RFC 4627 documents JSON and registers its media type.
  5. 2013ECMA-404 publishes a language-independent JSON syntax standard.
  6. 2014–2017RFC 7159, RFC 8259 and ISO/IEC 21778 clarify the format and its interoperability rules.
  7. TodayJSON is a common interchange format for APIs, configuration, logs and data tools.

Sources and further reading