What is JSON? A practical guide for developers

A text format, not a programming language

JSON is a way of writing down structured data as text so that two programs can exchange it. It was popularized by Douglas Crockford in the early 2000s and is now specified in RFC 8259 and in ECMA-404. Despite the name, it is not tied to JavaScript. Python, Go, Java, Rust, PHP, and nearly every other language ship a JSON parser, and the same document can be read by all of them.

The format borrows its syntax from the way JavaScript writes object literals, which is where the name comes from, but it deliberately uses only a tiny subset. There are no functions, no variables, no dates, and no comments. A JSON document is data and nothing else, which is exactly why it is safe and easy to pass between systems.

The six kinds of value

Every JSON value is one of six things: an object, an array, a string, a number, a boolean (true or false), or null. That is the complete list. An object is an unordered collection of name and value pairs wrapped in curly braces. An array is an ordered list of values wrapped in square brackets. Objects and arrays can contain other objects and arrays, which is how you get nesting of any depth.

Here is a small document that uses all six. It describes a build job, the sort of thing a CI service might return.

{
  "id": 1042,
  "branch": "main",
  "passed": true,
  "duration_seconds": 93.4,
  "failed_tests": [],
  "artifact": null,
  "author": {
    "name": "Priya",
    "email": "priya@example.com"
  }
}

The syntax rules that cause most errors

JSON is far less forgiving than a JavaScript object literal. Keys must be strings, and strings must use double quotes. Single quotes are invalid. Trailing commas after the last item in an object or array are invalid. Comments, whether // or /* */, are invalid. Numbers cannot have leading zeros (so 007 is wrong), cannot start with a plus sign, and cannot be written as hex. NaN and Infinity do not exist in JSON at all. The literals true, false, and null must be lowercase.

Inside strings, a few characters must be escaped: the double quote, the backslash, and control characters below U+0020 such as newline, which is written \n. Any Unicode character can also be written as \uXXXX. Whitespace between tokens is allowed and ignored, which is the only reason pretty-printing is possible.

The next snippet is what people often paste when they copy from code rather than from a real response. It is not valid JSON, and a parser will reject it at the first single quote.

{
  'name': 'Priya',      // the author
  retries: 3,
  "tags": ["ci", "nightly",],
}

JSON versus a JavaScript object

The most common confusion is between a JSON string and a JavaScript object. A JavaScript object lives in memory and can hold functions, undefined, dates, and circular references. JSON is text. You convert between the two with JSON.stringify, which turns a value into text, and JSON.parse, which turns text back into a value.

The conversion is lossy in a few predictable ways. Properties whose value is undefined or a function are dropped from objects, and a Date becomes an ISO 8601 string because Date has a toJSON method, so parsing it back gives you a string rather than a Date. NaN and Infinity are turned into null. If you have ever wondered why a round trip changed your data, it is usually one of these.

const original = { when: new Date("2025-03-01T10:00:00Z"), note: undefined, ratio: NaN };
const text = JSON.stringify(original);
console.log(text);
// {"when":"2025-03-01T10:00:00.000Z","ratio":null}
console.log(JSON.parse(text).when instanceof Date); // false

Numbers, encoding, and other quiet details

JSON itself does not distinguish integers from floating point numbers; it only defines a textual format for numbers. What happens to them depends on the parser. JavaScript reads every number as a 64-bit float, so integers larger than 9007199254740991 (2^53 minus 1) can silently lose precision. If you are passing database IDs that big, send them as strings.

RFC 8259 requires JSON exchanged between systems to be encoded as UTF-8, and says a byte order mark must not be added. If a file refuses to parse and the first character looks invisible, a BOM is a good suspect. Also note that the spec says object keys should be unique, but parsers disagree on what to do with duplicates. Most keep the last one, and some keep the first, so do not rely on either behavior.

Finally, the top level does not have to be an object. Since RFC 7159 and now RFC 8259, a bare value such as 42, "hello", or [1, 2, 3] is a perfectly valid JSON text, though older parsers may insist on an object or array.

Where you will actually meet JSON

The obvious place is HTTP APIs: a client sends a request body and the server answers with JSON, usually with the Content-Type header set to application/json. Configuration is the second big area. Files like package.json, tsconfig.json, and many editor settings are JSON, although some of those tools quietly accept comments through a relaxed parser, which is not standard JSON.

Logging is the third. Structured logs write one JSON object per line, which lets log tools filter on fields instead of grepping text. Databases such as PostgreSQL and MongoDB store JSON or a close relative of it, and many message queues carry it as the payload. In all of these, you will spend more time reading JSON than writing it, and that is where readability matters.

Reading a large document without losing your place

A real API response can run to thousands of lines with arrays of objects nested three or four levels deep. Raw text is a poor way to understand that. A tree view lets you collapse the branches you do not care about, and a table view is a better fit when an array holds many objects with the same keys.

View My JSON is a free web app at app.viewmyjson.com where you can paste text or drop a .json file and look at it as Cards, Table, or Tree, with Format and Validate alongside. The parsing happens in your browser, and the core tools need no account. That is handy when you want to check a response quickly. The syntax rules above are the part to remember whichever tool you use, because they explain nearly every parse error you will see.