What Is JSON? The Data Format That Runs the Web

JSON — JavaScript Object Notation, pronounced “JAY-son” — is a lightweight, text-based format for representing structured data. It is the data format the web runs on. Open the network tab in your browser’s developer tools, click almost any API request, and the response body will be JSON. It’s the language that servers and clients use to pass structured data back and forth, and it’s straightforward enough to read without a decoder ring.

The syntax

JSON has exactly six value types:

• Object — a collection of key/value pairs, wrapped in {}. Keys are always strings.
• Array — an ordered list of values, wrapped in [].
• String — text, wrapped in double quotes: "hello".
• Number — an integer or decimal: 42, 3.14.
• Boolean — true or false.
• Null — the explicit absence of a value: null.

These six types nest freely, which is what makes JSON expressive enough for real-world data. Here’s a representative JSON document:

{
  "user": {
    "id": 1042,
    "name": "Morgan Rivera",
    "email": "morgan@example.com",
    "verified": true,
    "score": 4.8,
    "tags": ["premium", "beta-tester"],
    "address": null
  }
}

That’s the whole grammar. No schemas required to read it, no special tools needed to write it.

The rules that trip people up

JSON’s grammar is strict, and most “invalid JSON” errors come from a short list of gotchas:

• Keys must be double-quoted strings. {name: "Morgan"} is a valid JavaScript object literal but invalid JSON. Single quotes don’t work either.
• No trailing commas. ["a", "b",] fails to parse. This is probably the single most common hand-written JSON error.
• No comments. The format deliberately omits them (more on workarounds below).
• Only null, not undefined, NaN, or Infinity. Those are JavaScript concepts, not JSON values — serializers either error or silently convert them.
• Numbers are typically parsed as 64-bit floats. Integers above 2⁵³ lose precision in JavaScript, which is why APIs send database IDs and monetary amounts as strings.
• Duplicate keys are undefined behavior. Most parsers keep the last one, but the spec doesn’t promise it — never rely on it.

If a payload refuses to parse, one of these is almost always the culprit.

Language-independent despite the name

The “JavaScript” in JSON is a historical accident. JSON syntax is borrowed from JavaScript object literals, but JSON is a completely language-independent text format. Every major programming language has built-in or standard-library support for parsing and generating it:

# Python
import json
data = json.loads('{"name": "Morgan", "score": 4.8}')
print(data["name"])  # Morgan

// JavaScript
const data = JSON.parse('{"name": "Morgan", "score": 4.8}');
console.log(data.name); // Morgan

The same text goes in, and you get a native data structure out — a dictionary in Python, an object in JavaScript, a map in Go, a hash in Ruby. That universality is a big part of why JSON won.

Where JSON shows up

REST API responses. This is the dominant use case. When an app fetches your profile, retrieves a product listing, or submits an order, both the request and response bodies are almost certainly JSON, sent with the application/json MIME type.

Configuration files. package.json (Node.js projects), tsconfig.json (TypeScript), VS Code settings, ESLint rules — a huge portion of developer tooling is configured via .json files.

Logs and events. Structured logging systems emit each log line as a JSON object so downstream tools can filter and query by field.

Document databases. Databases like MongoDB and Firestore store records as JSON-like documents, and PostgreSQL has a native jsonb column type for querying JSON data with SQL.

Tokens and credentials. JWTs — the tokens that power most stateless API authentication — are just signed JSON claims, base64url-encoded.

Working with JSON in practice

Every language ships the same two operations: parse (text in, data structure out) and serialize (data structure in, text out). In JavaScript, JSON.stringify takes a third argument that pretty-prints with indentation — JSON.stringify(data, null, 2) — which is worth memorizing for debugging.

Two practices pay off as systems grow:

• Validate at the boundary. Parsing only proves the text is syntactically legal, not that it has the fields your code expects. JSON Schema lets you declare the required shape — types, required keys, allowed ranges — and reject bad payloads with a useful error instead of a crash three functions later.
• Treat parsing as fallible. Wrap JSON.parse in error handling whenever the input crosses a trust boundary. Malformed JSON is a fact of life on the open web.

JSON vs XML

XML was the dominant data interchange format before JSON took over in the late 2000s. The same data in XML looks like this:

<user>
  <id>1042</id>
  <name>Morgan Rivera</name>
  <verified>true</verified>
  <tags>
    <tag>premium</tag>
    <tag>beta-tester</tag>
  </tags>
</user>

Both formats represent the same structure, but JSON wins on almost every practical dimension:

	JSON	XML
Verbosity	Compact	Verbose (open + close tags)
Readability	Easy	Harder for deep nesting
Native browser parsing	JSON.parse()	Requires DOMParser
Schema support	Optional (JSON Schema)	Built-in (XSD, DTD)
Comments	Not supported	Supported

XML still appears in legacy enterprise systems, some document formats (SVG, DOCX, RSS), and SOAP web services. For anything new, JSON is the default.

JSON vs YAML and the variants

For configuration files that humans edit constantly, many tools prefer YAML — it allows comments and reads more cleanly, at the cost of strictness. The trade-offs cut both ways; see our full JSON vs YAML comparison.

A few JSON dialects fill specific gaps:

• JSONC — JSON with comments, used by VS Code configuration files.
• JSON5 — a looser variant allowing comments, trailing commas, and unquoted keys; occasionally used for configs, never for APIs.
• JSON Lines (NDJSON) — one complete JSON object per line, the standard shape for log streams and large exports because each line parses independently.

These are conveniences at the edges. The interchange format — what APIs actually send — remains plain, strict JSON.

Common questions

How do I open a .json file?

Any text editor — a .json file is plain text. VS Code and modern editors add syntax highlighting and error checking, and every major browser will render a JSON URL with a built-in collapsible viewer.

Can JSON have comments?

No. The spec omits them intentionally, to keep parsers simple and prevent comments from being abused as parser directives. Workarounds: use a dedicated key like "_comment", or use JSONC/JSON5 for config files where your tooling supports it.

What is the correct MIME type for JSON?

application/json. You’ll see it in the Content-Type header of API requests and responses.

Is JSON a programming language?

No — it’s a data format. It has no variables, logic, or functions; it only describes structured values. That simplicity is precisely why every programming language can support it.

The takeaway

JSON is a simple, text-based format for representing structured data: six value types, two containers, and a syntax any developer can read at a glance. Because it maps cleanly onto data structures in every programming language and ships natively in every browser, it became the universal format for APIs and configuration. Know the handful of strict rules — double quotes, no trailing commas, no comments — validate payloads at trust boundaries with JSON Schema, and you know everything the format will ever ask of you.