The encyclopedia · Software & IT · Technical decision · 2001-2017
JSON won as an API lingua franca by being a subset of JavaScript
Douglas Crockford published JSON in 2001 as a JavaScript subset, so browsers could parse it natively; open and simple, it displaced XML in web APIs.
JSON.org
the move
In the early 2000s, web applications needed to move structured data between servers and browsers. XML had momentum but was verbose and needed parsers and schemas; working with it in JavaScript was painful, which is exactly where the data had to end up.
Douglas Crockford specified JSON as a lightweight format built on the two universal structures, name/value objects and ordered lists, and deliberately based it on a subset of the JavaScript Programming Language Standard (ECMA-262, 3rd Edition). A browser could therefore parse it natively, and the json.org specification was published openly for anyone to implement.
JSON spread first among web API builders, then everywhere. In 2017 the IETF published RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, which describes it as derived from the ECMAScript Programming Language Standard, and it became the default data-interchange format for web services.
why it works
- Native JavaScript syntax meant the most important client parsed it with zero extra machinery.
- The two data structures map directly onto every mainstream language's objects and arrays.
- An open, simple specification removed licensing and learning barriers.
what transfers
The winning format lowers the cost of the very first integration: by matching the native syntax of the dominant consumer, JSON made the first browser-side parse free, and every later port followed.
what came after
RFC 8259 formalized JSON as an IETF standard in 2017, and virtually every programming language ships a parser. It became the default payload for web APIs and the model for a generation of NoSQL document stores, while XML retreated to document-centric niches.
references
spotted an error? The archive wants to know.