JSON

• 1. Introduction

  ›

  JSON, which stands for JavaScript Object Notation and is pronounced either JAY-son or JAY-sawn, carries an unusual distinction for a data format: its name sounds exactly like a person's name. That coincidence was no accident. The format's creator, Douglas Crockford, was well aware of the parallel, and in 2011 he cheerfully declared, "There's a lot of argument about how you pronounce that, but I strictly don't care."

  Crockford and a colleague named Chip Morningstar sent the very first JSON message in April 2001. Within a few years, that simple act of transmission had set off a quiet transformation in how the web exchanged information. Today JSON is everywhere, the default language through which web applications talk to servers, databases talk to developers, and devices talk to each other.

  How did a format with roots in a children's trading game become an internet standard ratified by bodies in Geneva and Washington? And what exactly is hiding inside those curly brackets?

• 2. The Problem It Solved

  ›

  In the early 2000s, getting a web browser to talk to a server in real time meant relying on browser plugins like Flash or Java applets. These plugins were the dominant method of achieving live, back-and-forth communication, but they were heavyweight, proprietary, and not universally available.

  Crockford and his co-founders at State Software, a company they started in March 2001, set themselves a different goal. They wanted to build interactive web applications using only what browsers already had built in, without asking users to install anything extra. Their approach involved holding two HTTP connections open simultaneously and recycling them before standard browser timeouts kicked in, maintaining what they called a persistent duplex connection.

  The co-founders sat around a table and voted on what to call the new data format. The candidates were JSML, short for JavaScript Markup Language, and JSON. JSON won. What they needed was a lightweight way to pass structured data through those recycled connections, and they found it by recognizing that JavaScript itself could serve as an object-based messaging format. The system they built was eventually sold to Sun Microsystems, Amazon.com, and EDS.

• 3. Origins in a Children's Game

  ›

  Before State Software existed, there was Cartoon Orbit, a children's digital asset trading game run by a company called Communities.com. A precursor to the JSON libraries appeared there first, embedded in a browser-side plugin that used a proprietary messaging format to manipulate page elements in real time.

  It was through this early experiment that developers discovered what browsers could already do. Teams at companies called digiGroups and Noosh began using frames to push information into a browser's visible field without forcing a full page refresh. They were doing this with Netscape 4.0.5 and Internet Explorer 5, using nothing but standard HTTP, HTML, and JavaScript.

  Crockford recognized that this Ajax-like capability, long before the term Ajax was coined, could carry structured data shaped like JavaScript objects. The JSON.org website went live in 2001, and by December 2005 Yahoo! was offering some of its web services in JSON format. That adoption by Yahoo! was an early sign that the format had outgrown its origins in a startup's conference room.

• 4. What JSON Actually Looks Like

  ›

  JSON stores data as name-value pairs inside curly brackets, and lists of values inside square brackets. A key is always a string in double quotation marks, a colon separates it from its value, and commas separate each pair from the next.

  The format recognizes six data types. Numbers can be signed decimals with fractional parts or exponential notation, but not values like NaN. Strings are sequences of Unicode characters, delimited by double quotation marks. Booleans are simply the words true or false. Arrays are ordered lists in square brackets. Objects are collections of key-value pairs in curly brackets. And null represents an empty value.

  Whitespace is allowed anywhere between elements and is simply ignored. Four characters count as whitespace: space, horizontal tab, line feed, and carriage return. One thing JSON deliberately leaves out is comments. Crockford explained in 2012 that he removed them after seeing developers use them to embed parsing instructions, a practice he believed would have broken interoperability between different systems. His suggested workaround was to strip comments with a tool called JSMin before feeding the text to a JSON parser.

• 5. Standardization and the Good, Not Evil Clause

  ›

  JSON operated for years under an informal specification before formal standards bodies got involved. RFC 4627 had served as an informational reference since 2006, but the first true standard arrived in October 2013, when Ecma International published ECMA-404.

  Four years later, in November 2017, ISO/IEC JTC 1/SC 22 published its own standard, ISO/IEC 21778:2017. Then on the 13th of December 2017, the Internet Engineering Task Force published RFC 8259, the current version of Internet Standard STD 90. The ECMA and ISO/IEC documents cover only syntax; the RFC additionally addresses security and interoperability considerations.

  Before any of this, Crockford had introduced a clause into the JSON license that stated, "The Software shall be used for Good, not Evil." He framed it as a way to open-source the libraries while gently mocking corporate lawyers and those he saw as overly pedantic. The clause did carry a real consequence: it created compatibility problems with other open-source licenses, since standard open-source and free software definitions permit no restrictions on the purpose of use.

• 6. Interoperability Pitfalls

  ›

  JSON's simplicity is also a source of friction. Because the specifications place no limit on the magnitude or precision of numbers, different implementations handle edge cases differently. JavaScript itself stores all numbers as IEEE 754 binary64 values, and for broad compatibility the RFC recommends not transmitting numbers outside that range, citing values like 1E400 or the extended decimal expansion of pi as examples that could cause problems.

  Duplicate key names are another hazard. The ECMA standard explicitly permits JSON objects to contain multiple members sharing the same name, but it says nothing about what implementations should do with them. The behavior is left unpredictable, and the practical guidance is to simply avoid sending duplicate keys at all.

  In 2015, the IETF published a specification describing the "I-JSON Message Format," a restricted profile of JSON designed to head off as many of these interoperability issues as possible. On the character encoding side, while the specifications technically permit other encodings, nearly all implementations assume UTF-8, and RFC 8259 requires UTF-8 for open-ecosystem exchange. The format supports the full Unicode character set, including characters beyond the Basic Multilingual Plane, which runs from U+0000 to U+FFFF.

• 7. A Format That Spawned a Family

  ›

  JSON's deliberate minimalism left room that other formats rushed to fill. Comments, trailing commas, and unquoted keys are all features JSON excludes by design, and the absence of each generated its own workaround.

  JSON5, whose specification was started in 2012 and finished in 2018 with version 1.0.0, adds optional trailing commas, unquoted object keys, single-quoted and multiline strings, additional number formats, and comments, while remaining valid JavaScript syntax. HJSON and HOCON pursue similar goals: HOCON, which stands for Human-Optimized Config Object Notation, is used as the primary configuration format for TIBCO Streaming products including StreamBase and LiveView, as well as for subsystems of Exabeam Advanced Analytics and for Jitsi. YAML version 1.2 is a full superset of JSON, though earlier YAML versions were not strictly compatible.

  Beyond configuration, JSON spawned a family of specialized derivatives. GeoJSON handles geographical features. JSON-LD encodes linked data. JSON-RPC is a remote procedure call protocol built on JSON, intended as a replacement for XML-RPC or SOAP. UBJSON is a binary format that imitates JSON while using fewer bytes. Jsonnet extends JSON with variables, imports, loops, and comments, and is used as a configuration language for cloud infrastructure. Relational databases including PostgreSQL and MySQL have added native JSON data types, with PostgreSQL offering a binary storage variant called JSONB.