What Is JSON? A Beginner's Explanation

If you have ever opened a browser's network tab, poked at a package.json file, or read the docs for any web API built in the last fifteen years, you have already seen JSON. It is the text format that carries most of the data moving around the internet — and it is small enough that you can learn essentially all of it in a single sitting.

This post answers the beginner question directly: what JSON is, what it looks like, what the rules are, and why it beat the alternatives. For the deeper reference material — escape sequences, API practices, minification trade-offs — see The Complete Guide to JSON.

JSON, in one sentence

JSON (JavaScript Object Notation) is a plain-text format for representing structured data as key-value pairs and lists.

That is genuinely the whole idea. It is not a database, not a language, and not a protocol. It is a convention for writing down data as text so that a program written in Python can hand information to a program written in Go, and both agree on what it means.

The "JavaScript" in the name is historical. Douglas Crockford took the syntax from JavaScript object literals in the early 2000s and specified it as a standalone format. It is now standardised twice over — as ECMA-404 and RFC 8259 — and belongs to no particular language.

What JSON looks like

Here is a small but complete JSON document describing a user:

{
  "id": 1042,
  "name": "Priya Raman",
  "email": "priya@example.com",
  "verified": true,
  "nickname": null,
  "tags": ["designer", "beta-tester"],
  "address": {
    "city": "Bengaluru",
    "postcode": "560001"
  }
}

Even with no explanation you can probably read that. The self-describing quality is the point — it is why JSON won.

Structurally there are only two containers:

• Objects are wrapped in curly braces {} and hold named fields. You look things up by name: address.city.
• Arrays are wrapped in square brackets [] and hold an ordered list. You look things up by position: tags[0].

Everything else is a value that goes inside one of those containers. Choosing between the two is a real design decision once your data gets more complicated, which is why it has its own post on JSON arrays vs objects.

The six data types

JSON supports exactly six types, and no more:

Type	Example	Notes
String	"hello"	Double quotes only, always
Number	42, -3.5, 2.1e6	No separate integer type
Boolean	true, false	Lowercase only
Null	null	Lowercase; means "explicitly empty"
Array	[1, 2, 3]	Ordered list
Object	{"a": 1}	Named fields

What is not on that list matters as much as what is. There is no date type, no binary type, no comment syntax, and no undefined. Dates travel as ISO 8601 strings; binary travels as Base64; annotations have to live in your documentation or your code.

The rules that trip people up

JSON is deliberately strict, and beginners nearly always break it in the same four ways — usually because they are typing JavaScript or Python out of habit.

1. Keys must be in double quotes. {name: "Priya"} is fine in JavaScript and invalid in JSON.
2. Strings use double quotes, never single. {'name': 'Priya'} fails. This catches everyone who pastes a Python dictionary and expects it to parse.
3. No trailing comma. {"a": 1, "b": 2,} is an error. That last comma is legal in JavaScript, Python, and Rust, so the muscle memory is strong.
4. No comments. Neither // nor /* */ is allowed. A strict parser will reject the whole document.

Two smaller ones worth knowing: the literals must be lowercase (True, False, and None from Python are all invalid), and numbers cannot have a leading zero or a leading +.

When something does fail to parse, do not read the file character by character. Paste it into a JSON Validator — it reports the line and column where the grammar first broke, which usually makes the mistake obvious in seconds. If you want to know the specific error messages and what each one really means, we catalogue them in the post on common JSON syntax errors.

Why JSON took over

Before JSON, XML was the default for machine-to-machine data. The same user record above would run roughly three times longer in XML, because every field costs an opening and a closing tag. JSON's advantage came down to three things:

• Less overhead. Smaller payloads, faster to transmit, faster to parse.
• Native mapping. A JSON object becomes a dict in Python, a Map or object in JavaScript, a HashMap in Java — with one function call and no schema compiler.
• Readability. A developer can debug a JSON payload by reading it. That is not a trivial benefit when you are staring at a failing webhook at 2am.

XML is not dead; it still wins where schema validation, namespaces, and document transformation matter, and the trade-offs deserve a proper head-to-head, which is what our JSON vs XML comparison is for.

Where you will actually meet JSON

• APIs. Almost every REST API sends and receives JSON, marked with the Content-Type: application/json header.
• Config files. package.json, tsconfig.json, composer.json, VS Code settings, cloud IAM policies.
• Logs. Structured logging pipelines emit one JSON object per line so machines can query them.
• Databases. MongoDB, CouchDB, and Postgres jsonb columns all store JSON-shaped documents.
• Browser storage. localStorage only holds strings, so objects get stringified to JSON first.

Reading JSON you did not write

The first real difficulty beginners hit is not syntax — it is volume. An API response can be a single 40,000-character line with no whitespace, and no amount of squinting will make that legible.

Two moves fix it. Run the text through a JSON Formatter, which adds indentation and line breaks so the structure becomes visible; the process is covered step by step in how to format JSON. Then, when the document is deeply nested, switch to a JSON Tree Viewer, which renders it as a collapsible tree so you can fold away branches you do not care about and drill into the one you do.

Both tools run entirely in your browser. That matters more than it sounds: the JSON you most often need to inspect is a live API response containing a bearer token, a customer email, or an internal data shape. Nothing you paste is uploaded anywhere, so you can debug real production payloads without sending them to someone else's server.

The short version

JSON is text that describes data using named fields and ordered lists. It has six types, two containers, and a handful of strict rules — double quotes everywhere, no trailing commas, no comments. Learn those and you can read any JSON document you encounter, which in practice means most of the data on the modern web.

The fastest way to internalise it is to paste something real into a formatter and look at the shape. Grab a response from any public API, drop it in, and read the tree.