Skip to content
Getting Digital

JSON

Also: JavaScript Object Notation, JSON file, JSON document, JSON payload, JSON Schema

JSON is a text format for exchanging structured data: values are strings, numbers, booleans or null, arranged in ordered arrays and in objects of name and value pairs, and every mainstream language reads and writes it without a library of its own.

Assessment. JSON's small size and loose structure are the reasons for its adoption and the source of most problems with it. The format does not state which fields a document must contain or what a number represents, so any two systems that exchange JSON over time need a written contract. Teams that record the contract early, in JSON Schema or an API description, spend less time on missing fields and incorrect types.

JSON was lifted from the object literal syntax of JavaScript and standardised twice, as ECMA-404 and as RFC 8259 (December 2017), with both bodies keeping the grammar identical. The format is small: an object is a set of name and value pairs in braces, an array is an ordered list in brackets, and a value is one of six things, a string, a number, true, false, null, or another object or array. Names are strings. Whitespace is free. There is nothing else, which is why a parser exists for every language and why a document written by a Python service is read by a browser, a Go program and a spreadsheet import without conversion.

The format appears in more places than its simplicity suggests. Nearly every REST API answers in it, and a request body sent over HTTP is JSON more often than any other shape. Configuration files use it (package.json in every JavaScript project), log lines are written as one JSON object per line so that tools can filter them by field, document databases store it directly, and large language models are asked to answer in it so that a program can read the answer. Learning to read a JSON document is therefore a prerequisite for back-end work, for most front-end work and for a good part of data analysis.

Value typeLooks likeCommon error
string"text in double quotes"Single quotes are not JSON; a date is a string the reader has to parse
number42, 3.14, -1e9No integer or decimal distinction; large integers lose precision in JavaScript
boolean, nulltrue, false, nullA missing field and a null field are different things to most code
object{ "name": "value" }Duplicate names are allowed by the grammar and handled differently by parsers
array[1, 2, 3]Order carries meaning; a reordered array is a changed document

What JSON omits explains most of the difficulties encountered with it. There are no comments, so configuration files cannot explain themselves. There is no date type, no binary type and no way to reference one part of a document from another, so dates travel as strings in whichever convention the writer chose and files travel as base64 text. There is no schema in the format itself; JSON Schema, a separate specification, describes which fields are required and of which type, and OpenAPI descriptions of REST interfaces embed it for the same purpose. A team that adopts one of them gets validation at the boundary and documentation for free.

In practice

  • The document: an order as an object with an id (number), a customer (object with name and email), items (an array of objects with sku and quantity) and a placedAt string in ISO 8601 form.
  • The reading: a front end shows the customer name, a warehouse service sums the quantities, an analyst flattens the array into one row per item. Three consumers, one document, no translation layer.
  • The failure: a new version of the back end sends quantity as the string "2" after a refactor. JavaScript concatenates it, Python raises, the spreadsheet import shows text. A schema check at the boundary would have rejected the document before anyone noticed.

Often confused with

REST API
REST is a style for designing an interface over HTTP; JSON is the format the interface usually sends and receives. An API can be RESTful and answer in XML, and JSON travels over message queues and files that have nothing to do with REST.
HTTP
HTTP is the protocol that carries a request and its response; JSON is one possible shape of the body inside them. The headers say what the body is, and the body, often, is JSON.

Key takeaways

  • →Six value types, two structures, no comments, no dates: the format's small size is the reason for its ubiquity.
  • →The contract is not in the document. Write it down in JSON Schema or an API description before two teams depend on it.
  • →Numbers and dates are where JSON goes wrong in practice: precision in JavaScript, string conventions everywhere.

Related concepts

  • RelatedREST API

    JSON is the body format most REST interfaces send and receive.

Where this concept sits in the field

Certifications that test this

Vendor exams whose syllabus covers this concept: facts, cost and a preparation path on each page.

FAQ

Is JSON the same as a JavaScript object?
It started as a subset of JavaScript's object syntax, and a JSON document is valid JavaScript, but the format is independent now: names must be double-quoted strings, trailing commas are not allowed, and values such as functions or undefined do not exist. Every language has a parser, so JSON belongs to no language in particular.
When should a project use XML, YAML or something else instead?
YAML is easier for humans to write and read, with comments, and is the usual choice for configuration that people edit by hand; it is also easy to get wrong through indentation. XML carries schemas, namespaces and mixed text, which some industries still require. For data that programs exchange, JSON is the default unless a counterpart insists otherwise.
Does JSON need a schema?
The format does not require one, and small projects run without. As soon as two teams or two services depend on the same documents, a schema (JSON Schema, or the models in an OpenAPI description) saves the hours otherwise spent on fields that are missing, renamed or sent as the wrong type.

Sources

The primary text this definition rests on. Read it before relying on this one.

Last reviewed 3 October 2026 · Getting Digital