What JSON can and cannot hold
Six types, no comments, no dates — and everything else is a convention on top.
The whole type system
JSON has objects, arrays, strings, numbers, booleans and null. That is all of it. There is no date type, no integer type distinct from a float, no binary, no reference between parts of a document.
Everything else is a convention agreed between the writer and the reader. A date is a string in an agreed shape — ISO 8601, because it sorts correctly as text and has no regional ambiguity. Binary is usually base64 in a string, at a third more bytes.
Keys are always strings, even when they look like numbers: {"1": true} has the key "1". Languages that convert keys to numbers on parse will quietly change your data, and it is worth knowing which yours does before it matters.
The three things people expect and do not get
No comments. JSON has none, deliberately, and a config file with // in it is not JSON — which is why tools invented JSON5, JSONC and friends rather than extending it. If a parser accepts them, something non-standard is doing the accepting.
No trailing commas. {"a": 1,} is a parse error in strict JSON, and it is the single most common reason a hand-edited file will not load.
Key order is not guaranteed to be meaningful. Most parsers preserve insertion order and most people rely on that, but nothing in the format promises it, so do not encode meaning in the order of keys.
Worked examples
A date, the only way JSON can carry one
/{"published": "2026-09-21T10:30:00Z"}/Against:
ISO 8601, in UTCSorts correctly as text and has no 09/10 ambiguity. Local times without an offset are the thing that goes wrong six months later.
Check yourself
Practice questions written for this lesson — not past exam papers.
Practise every question in this subject
How does JSON represent a date?
Why is {"a": 1,} a problem?