JSON

The plain-text data format of web APIs: objects, arrays, strings, numbers, booleans and null, with one small grammar every language can parse.

What it is: File formats (text and markup)
Type: Open source
Made by: IETF and Ecma International (open standard)
License: Open standard, free to use; ECMA-404 is also ISO/IEC 21778
Facts checked: 6 October 2026

What it is

JSON is a text syntax, not a program. A JSON text is one value: an object ({"name": value, …}), an array ([…]), a string in double quotes with backslash escapes, a number, true, false or null. That is the whole type system. There are no comments, no dates, no binary data and no NaN or Infinity. RFC 8259 requires UTF-8 whenever JSON travels between systems that aren’t part of one closed ecosystem, and lets parsers set their own limits on size, nesting depth and the range and precision of numbers. Most use IEEE 754 doubles, so integers are only guaranteed to survive a round trip between −(2^53−1) and 2^53−1. Object names “SHOULD be unique”; when they aren’t, parsers disagree about which value wins.

For data files the usual form is JSON Lines, also called newline-delimited JSON (NDJSON): one JSON value per line in UTF-8, so a file can be appended to, streamed and split without parsing it whole. To describe and validate documents, teams add JSON Schema, a separate specification whose latest version is 2020-12. The syntax itself is defined twice, in IETF RFC 8259 (an Internet Standard) and Ecma’s ECMA-404 (also ISO/IEC 21778), both from December 2017 and kept aligned on purpose. Anyone can use it for free, and every mainstream language ships a parser.

Why teams pick it

Parsers for practically every language (json.org lists dozens), and built into JavaScript since ECMAScript 5
Maps directly onto the objects or dictionaries and arrays or lists that programs already use
A grammar small enough to fit on one page, so documents are easy to read, diff and generate
JSON Lines makes logs and event files append-friendly and streamable, one record per line

Watch out for

No comments, which makes it awkward for hand-edited configuration
Number precision is left to each parser: IDs above 2^53 silently change in JavaScript, so I-JSON (RFC 7493) recommends sending big or exact numbers as strings
No binary or date types: binary goes in base64url strings, about a third bigger than the raw bytes, and dates are strings by convention
Every record repeats its field names as text, and it’s a row format, so analytical scans read everything; convert to Parquet for querying
Duplicate keys, member order and very large numbers are handled differently by different parsers, which RFC 8259 calls out as interoperability problems

Alternatives

What all text and markup have in common →

TOMLOpen sourceA minimal configuration format with explicit types that maps unambiguously to a hash table; the language of `Cargo.toml` and `pyproject.toml`.

XMLOpen sourceThe W3C’s markup language for trees of tagged text, still behind Office documents, SVG, feeds, SOAP and the S3 API.

YAMLOpen sourceThe indentation-based text format behind most cloud configuration: Kubernetes manifests, CI workflows and Compose files.

How it fits with other technologies

What JSON uses

What uses JSON

JSON Lines with jq, and the 2^53 precision trap · bash

# one JSON object per line: JSON Lines, also called NDJSON
cat > events.jsonl <<'EOF'
{"ts":"2026-10-06T09:00:00Z","user_id":42,"event":"login"}
{"ts":"2026-10-06T09:00:05Z","user_id":7,"event":"purchase","amount":19.99}
{"ts":"2026-10-06T09:01:12Z","user_id":42,"event":"purchase","amount":5.00}
EOF

# jq treats each line as its own value
jq -c 'select(.event == "purchase") | {user_id, amount}' events.jsonl
# {"user_id":7,"amount":19.99}
# {"user_id":42,"amount":5.00}

jq -n '[inputs | select(.event == "purchase") | .amount] | add' events.jsonl
# 24.99

# integers above 2^53 don't survive parsers that use doubles
echo '{"order_id": 9007199254740993}' | node -p 'JSON.parse(require("fs").readFileSync(0, "utf8")).order_id'
# 9007199254740992

JSON, YAML, TOML and XML side by side#

Four text formats for structured data. They overlap, but each grew up around a different job, and that shows in what they leave out.

	JSON	YAML	TOML	XML
Current spec	RFC 8259 and ECMA-404 (both December 2017)	YAML 1.2.2 (October 2021), a revision of 1.2 from 2009	TOML 1.1.0 (December 2025)	W3C XML 1.0, Fifth Edition (November 2008)
Comments	None	`#` to the end of the line	`#` to the end of the line	`<!-- … -->`
Built-in value types	String, number, boolean, null	Null, boolean, integer, float and string in the recommended core schema; others through tags	String, integer, float, boolean, offset and local date-times, dates and times	None: content is text until a schema gives it types
Nesting	Objects and arrays	Mappings and sequences; anchors and aliases reuse a node	Tables, arrays, inline tables and arrays of tables	Elements with attributes; namespaces mix vocabularies
Schema language	JSON Schema, a separate spec (latest 2020-12)	None; the spec’s “schemas” only decide how unquoted values are typed	None in the spec	DTDs (part of XML 1.0), W3C XML Schema (XSD), RELAX NG
Typical use	Web API bodies; JSON Lines logs and events	Kubernetes manifests, GitHub Actions workflows, Compose files	`Cargo.toml`, `pyproject.toml`, Telegraf config	Office documents, SVG, RSS and Atom feeds, SOAP, the S3 API

Each cell is taken from the format’s own specification, and typical uses from the documentation of the tools named. The same table appears on the JSON, YAML, TOML and XML pages.

See it in a real stack

No architecture uses JSON yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2001–2017

Data formats at the turn of the century were either ad hoc or modelled on databases and documents, XML above all. Douglas Crockford, then CTO of State Software, found in April 2001 that JavaScript’s own object literals were an ideal way to send data across the network; by his account, several other people discovered the same thing independently. In 2002 he bought the json.org domain and put up a page describing the format as a subset of ECMA-262, 3rd edition.

By his account, it spread with no further effort on his part. In July 2006 Crockford published RFC 4627 to register the application/json media type, listing its design goals as “minimal, portable, textual, and a subset of JavaScript.” That December he presented JSON at the XML 2006 conference as “the fat-free alternative to XML.” ECMAScript 5 built a JSON object into the language in 2009, and the syntax became a formal standard twice: ECMA-404 in 2013, and RFC 8259, an Internet Standard aligned with ECMA-404, in December 2017.

Why it’s built this way

Borrow JavaScript’s object literal syntax: Browsers could already read it, and its strings, numbers, objects and arrays looked like the data structures of C-family languages, so programmers needed no new model.
No version number: Crockford wrote that “no revisions to the JSON grammar are anticipated”, so a JSON text from 2002 still parses today and no reader has to check versions.
No NaN, Infinity, hex or octal numbers: To stay minimal, and because JSON “does not want to be tied to any particular internal representation” of numbers. The cost is that precision is left to each parser.
No built-in validator: Crockford argued that being well-formed isn’t the same as being correct, so every application has to validate its own input. Schemas came later, from the separate JSON Schema project.

Timeline

2001
Crockford starts sending JavaScript object literals as data at State Software
2002
json.org goes up with the grammar
2006
RFC 4627 registers application/json (July)
2009
ECMAScript 5 adds a built-in JSON object (December)
2013
ECMA-404 first edition (October)
2017
RFC 8259 and ECMA-404 2nd edition published together (December)

Sources32 · facts checked 6 October 2026

Improve this page on GitHub