What Is JSON? A Plain-Language Introduction

JSON stands for JavaScript Object Notation. It was derived from the way JavaScript writes objects, but it is now language-independent: virtually every programming language can read and write it. At its core, JSON is just text arranged so that a parser can rebuild the same nested structure of values on the other side — whether that is a web server, a mobile app or a database.

The format became popular because it hits a sweet spot: it is compact enough to send over a network quickly, yet readable enough that a developer can scan it by eye. That balance is why it replaced heavier formats for most web communication.

The notation was popularised by Douglas Crockford in the early 2000s and has since been standardised twice over: ECMA-404 describes the grammar, and RFC 8259 defines the application/json media type and the interchange rules that go with it. Both documents are short — the entire grammar fits on a single page — and that smallness is the point. A format with few rules has few corner cases, so two independent parsers written a decade apart still agree on what a document means.

JSON supports exactly six kinds of value. Two are containers: the object, written with curly braces as a set of "key": value pairs, and the array, written with square brackets as an ordered list. The other four are primitives: string (always in double quotes), number (integer or floating point), boolean (true or false) and null. Objects and arrays can nest inside each other to any depth, which is how JSON represents complex, tree-shaped data.

Notice what is missing: there is no date type, no comment syntax and no way to write a function. Dates are usually stored as strings (often in ISO-8601 form) and interpreted by the application, not by JSON itself.

JSON is strict, and that strictness is a feature — it means any valid document parses the same way everywhere. Keys and string values must use double quotes, never single. There are no trailing commas after the last item in an object or array. Every opening brace or bracket needs a matching close. Break one of these rules and a parser rejects the whole document, which is exactly when a formatter and validator earns its keep.

Paste any document into the JsonCraft formatter and it will either pretty-print it with indentation and a collapsible tree, or point to the exact character where the syntax breaks. That immediate feedback is the fastest way to learn the rules by doing.

In transit a JSON document is a byte stream with the media type application/json and, by RFC 8259, an encoding of UTF-8. That single fixed encoding removes a whole class of problems that plague older formats: there is no charset to negotiate and no declaration line to get wrong. Characters outside ASCII may be written literally or escaped as \uXXXX sequences, and both forms parse to the same string, which is why an emoji survives a round trip through a well-behaved API unchanged.

One document per request is the usual pattern, but not the only one. Log pipelines and data exports often use JSON Lines — sometimes called NDJSON — where each line is a complete, self-contained JSON value terminated by a newline. That layout lets a consumer stream a multi-gigabyte file record by record without holding it all in memory, and a truncated download costs you only the final line rather than the entire file.

JSON has one number type, and most parsers map it to a 64-bit floating-point value. Integers stay exact up to 2^53 − 1, so an identifier longer than about sixteen digits can lose its last digits in a round trip. Systems that hand out large numeric IDs therefore send them as strings. Leading zeros, hexadecimal literals and a trailing decimal point are all invalid, and neither NaN nor Infinity can be expressed at all.

Two other details cause quiet bugs. The specification does not forbid duplicate keys, but it does not define what they mean either: most parsers keep the last one, some keep the first, and a few raise an error. Object key order is likewise not significant — treat an object as unordered even though many libraries preserve insertion order in practice. If your data depends on order, put it in an array, which is ordered by definition.