A lightweight, human-readable text format for representing
structured data as key-value pairs and ordered lists.
What is it?
JSON (JavaScript Object Notation) is a text-based data format
that stores information as key-value pairs and arrays. It
was derived from JavaScript’s object syntax in the early 2000s, but
despite the name, JSON is completely language-independent --- it
works in Python, Java, Ruby, Go, and virtually every other modern
programming language.1
JSON has become the lingua franca of the web. When a weather
app fetches today’s forecast, the server almost certainly sends the
data back as JSON. When a configuration file needs to store
settings, JSON is one of the most common choices. When an AI agent
calls an API, the request and response are usually
formatted in JSON.2
Its popularity comes from a rare combination: it is simple enough
for humans to read and edit by hand, yet structured enough for
machines to parse and generate efficiently. This dual readability
is what sets it apart from older formats like XML.3
In plain terms
JSON is like a labelled filing cabinet. Each drawer has a
name (the key) and contains something (the value) --- a single
fact, a list of items, or another smaller cabinet nested inside.
Anyone who knows the drawer names can find what they need.
Key: A JSON document is either an object (curly braces,
containing key-value pairs) or an array (square brackets,
containing an ordered list of values). Values can nest
recursively --- objects inside objects, arrays inside arrays.
How does it work?
Key-value pairs
The fundamental unit of JSON is a key-value pair. The key is
always a string in double quotes. The value can be one of six
types: string, number, boolean (true/false), null, object,
or array.1
The colon separates key from value. Pairs are separated by commas.
Think of it like...
A key-value pair is a question and answer on a form. The key is
the label (“Name:”), and the value is what you fill in
(“Ada Lovelace”). The form only makes sense if every field has a
label.
Objects
A JSON object is a collection of key-value pairs wrapped in
curly braces { }. Objects are unordered --- the pairs can
appear in any sequence, and the meaning does not change.1
Each key within an object must be unique. You cannot have two keys
called "city" in the same object.
Arrays
A JSON array is an ordered list of values wrapped in square
brackets [ ]. Unlike objects, the order of items in an array
matters.1
{ "languages": ["Python", "JavaScript", "Rust"]}
Arrays can contain any JSON value type, including other arrays or
objects. This is how JSON represents collections --- a list of
users, a set of coordinates, a sequence of events.
Nesting is like Russian dolls. The outermost doll (the root
object) contains smaller dolls (nested objects and arrays), each
of which can contain even smaller dolls. You open one level at a
time to find what you need inside.
Note what JSON does not support: comments, dates (they must be
encoded as strings), functions, or undefined. These constraints
keep the format simple and unambiguous.1
Key distinction
JSON looks like JavaScript, but it is not JavaScript. JSON
keys must be in double quotes. JSON cannot contain functions or
trailing commas. A JavaScript object is valid code; JSON is a
data format that any language can read.2
Parsing and serialisation
Converting a JSON string into a data structure your program can
work with is called parsing (or deserialisation). Converting a
data structure back into a JSON string is called serialisation
(or stringification).4
Each concept is a key in the outer object. Its value is a nested
object containing metadata as key-value pairs and relationships
as arrays. This is JSON doing exactly what it does best:
representing structured, hierarchical data in a format that both
humans and scripts can read.
Why do we use JSON?
Key reasons
1. Human-readable. Unlike binary formats, you can open a JSON
file in any text editor and immediately understand its structure.
This makes debugging and manual editing practical.
2. Universal compatibility. JSON is supported natively or via
standard libraries in virtually every programming language, making
it the default choice for data exchange between systems.1
3. Lightweight. Compared to XML, JSON uses fewer characters
to represent the same data --- no closing tags, no attributes. A
JSON payload is typically 30-50% smaller than its XML
equivalent.3
4. API standard. JSON is the dominant format for web APIs.
When a client sends a request to a server and receives data back,
that data is almost always JSON.2
When do we use JSON?
When exchanging data between a client and server via an API
When storing configuration for applications, tools, or frameworks (e.g., package.json, tsconfig.json)
When saving structured data to a file that both humans and machines need to read
When defining schemas or data models that describe the shape of other data
When working with NoSQL document databases that store records as JSON-like documents
Rule of thumb
If the data is structured (not free-form prose) and needs to
travel between systems or be read by both humans and code, JSON
is almost certainly the right format.
How can I think about it?
The recipe card
A recipe card is a real-world JSON object.
The card itself is the object (wrapped in { })
“title” is a key, "Chocolate Cake" is its string value
“servings” is a key, 8 is its number value
“ingredients” is a key, its value is an array --- an ordered list of items
“oven” is a key, its value is a nested object: { "temp": 180, "unit": "C" }
“vegetarian” is a key, true is its boolean value
Every piece of information has a label (key) and a value. You can
find any fact by knowing its label --- just like accessing
recipe.oven.temp in code.
The address book
A paper address book is a JSON array of objects.
The book itself is the array (wrapped in [ ]) --- an ordered list of entries
Each entry is an object with keys like "name", "phone", "address"
The address field is a nested object: { "street": "...", "city": "...", "zip": "..." }
Some entries have an email key, others do not --- JSON allows this flexibility
The entire book is serialisable --- you could copy it as text, send it to someone, and they could parse it back into a usable contact list
This maps directly to a common API pattern: requesting a list of
records from a server and receiving a JSON array of objects.