Overview
JSON (JavaScript Object Notation) is a lightweight data interchange format that has become the dominant standard for transmitting structured data between web servers and clients, between microservices, and between applications and their configuration files. Its appeal lies in a near-perfect combination of human readability and machine parseability: a JSON document looks natural to a programmer's eye while being trivial for any language to parse into native data structures.
JSON supports six value types: strings (Unicode text in double quotes), numbers (integer or floating-point), booleans (true/false), null, objects (unordered collections of key-value pairs wrapped in curly braces), and arrays (ordered sequences of values wrapped in square brackets). These six types are sufficient to represent the vast majority of real-world data structures, from simple configuration settings to deeply nested API responses.
JSON's syntax is a strict subset of JavaScript object literal notation, which is why it integrates so naturally with web development. However, JSON is language-independent — every major programming language provides a JSON library, and many include one in their standard library. The format's ubiquity in web APIs has made it the default choice for REST services, GraphQL responses, configuration files (package.json, tsconfig.json), document databases (MongoDB, CouchDB, Elasticsearch), and real-time messaging protocols (WebSocket payloads, MQTT messages).
History
Douglas Crockford is credited with discovering and popularizing JSON in the early 2000s, though he has described it as a format that was already in use by JavaScript developers before he gave it a name and a specification. The json.org website, which Crockford launched in 2002 with a concise grammar expressed in railroad diagrams, became the de facto reference. IETF standardized JSON as RFC 4627 in July 2006, and an updated specification, RFC 8259, was published in December 2017 along with the ECMA-404 standard.
JSON rose to prominence as an alternative to XML for web service communication. While XML-based SOAP was dominant in enterprise systems of the early 2000s, the simpler JSON format became the preferred choice for the emerging REST and AJAX paradigms championed by companies like Google, Yahoo, and Twitter. By the early 2010s, JSON had decisively won the API format wars, and today it is virtually the only format used for public web APIs.
Technical Details
A JSON document is a UTF-8 encoded text file (though UTF-16 and UTF-32 are also technically valid). The grammar is minimal: whitespace (spaces, tabs, newlines) is insignificant except within strings. Strings must use double quotes (not single quotes) and support escape sequences including \n (newline), \t (tab), \\ (backslash), \" (double quote), and \uXXXX (Unicode code point). Numbers follow the format of decimal floating-point literals without leading zeros, supporting optional negative sign, decimal point, and exponent (e.g., -3.14e10).
JSON has no date type — dates are typically serialized as ISO 8601 strings (2024-01-15T10:30:00Z). There is no comment syntax in standard JSON (a deliberate design decision by Crockford to prevent abuse), though variants like JSON5 and JSONC add comment support. JSON Schema (a separate specification) provides a vocabulary for describing the expected structure and constraints of JSON documents, enabling validation of API payloads, configuration files, and data imports. The maximum nesting depth and number precision are implementation-dependent; in JavaScript, numbers exceeding 2^53 lose precision because they are stored as IEEE 754 doubles.
Pros & Cons
Pros
- Human-readable syntax that is intuitive for developers and non-developers alike
- Native parsing support in virtually every programming language
- Lightweight and minimal — less syntactic overhead than XML
- De facto standard for REST APIs, configuration files, and document databases
- JSON Schema provides optional validation without complicating the base format
Cons
- No comment support in standard JSON, complicating annotated configuration files
- No native date/time type — dates must be encoded as strings by convention
- Large numeric precision loss in JavaScript-based parsers (integers beyond 2^53)
- Verbose for very large datasets compared to binary formats like Protocol Buffers
- No streaming parser standard — entire document typically loaded into memory
Common Use Cases
- Transmitting data between web servers and browser clients in REST and GraphQL APIs
- Storing application configuration (package.json, tsconfig.json, eslint.json)
- Persisting documents in NoSQL databases like MongoDB, CouchDB, and Elasticsearch
- Exchanging messages in real-time protocols (WebSocket, MQTT, SSE payloads)
- Defining infrastructure as code in tools like Terraform, CloudFormation, and ARM templates
- Serializing and deserializing application state for caching, logging, and debugging