JSON

JSON is a way to write down data as plain text so that one program can hand it to another. It came out of JavaScript in the early 2000s, but it stopped being a JavaScript thing a long time ago. Today a Python service, a Java service, and a Rust service can all exchange JSON without sharing a single line of code.

The format has exactly six data types: strings (text in double quotes), numbers, booleans (true or false), null, arrays (an ordered list in square brackets), and objects (an unordered set of key-value pairs in curly braces). Keys in an object are always strings. That is the entire specification. There are no dates, no comments, no integers separate from floats, and no trailing commas allowed.

A small example: {"id": 42, "name": "Ada", "active": true, "roles": ["admin", "editor"], "manager": null}. A beginner can read that at a glance, which is a large part of why JSON won over older formats like XML.

JSON is just a string of characters that follows a strict grammar. To use it, a program runs a parser that walks through the text character by character and turns it into native data structures, an object becomes a hash map or dictionary, an array becomes a list. Going the other way is called serialization: you take an in-memory object and write it out as a JSON string. In JavaScript these are JSON.parse and JSON.stringify; in Python they are json.loads and json.dumps.

Because JSON is text, it travels well. It goes inside HTTP request and response bodies, gets stored in log lines, and sits in database columns. The standard MIME type is application/json, and it is almost always sent as UTF-8.

The trade-off for being human-readable is size and speed. Numbers and keys are spelled out as text, so a JSON payload is larger than a tightly packed binary format, and parsing text is slower than reading fixed-width bytes. For most web traffic this does not matter once you turn on gzip or Brotli compression, which shrinks repetitive JSON dramatically.

Reach for JSON when humans need to read the data, when you are building or calling a web API, or when you need something every language understands with zero setup. Config files, REST and GraphQL responses, webhook payloads, and document databases all lean on it.

Avoid it, or wrap it, when you need maximum throughput or strict typing. High-volume internal services often prefer Protocol Buffers or Avro, which are binary, smaller, and carry a schema. JSON itself has no schema, so a field can silently change type between requests unless you validate it with something like JSON Schema.

Two sharp edges bite people repeatedly. First, JSON has no native date type, so dates travel as strings, usually ISO 8601 like 2026-06-14T10:00:00Z, and both sides have to agree on the format. Second, JSON numbers have no defined precision, and JavaScript parses every number as a 64-bit float, so a large 64-bit integer ID can lose accuracy past 2^53. The common fix is to send big IDs as strings.

Say a mobile app asks a server for a user profile. It sends an HTTP GET to /users/42 with the header Accept: application/json. The server queries its database, builds an object in memory, serializes it to a JSON string, and returns it with Content-Type: application/json.

The response body might be {"id": "42", "name": "Ada", "email": "ada@example.com", "createdAt": "2026-06-14T09:30:00Z"}. The app parses that string back into a native object and binds the fields to the screen.

This same pattern runs billions of times a day. The Stripe payments API, the GitHub API, and nearly every public API you can name speak JSON for both requests and responses, which is why learning to read and write it is one of the first practical skills in backend and frontend work.