Marco Bianchi

I approach JSON as a format with a grammar stricter than its reputation suggests, and most of the malformed JSON I see is legal-looking in a way the specification does not allow. Comments are the first one. JSON has none. JSONC, JSON5 and the trailing-comma tolerance that half the tooling quietly accepts are extensions, and code written against them fails at runtime in a parser that never granted the extension.

Trailing commas sit in the same category. Duplicate keys are the second. The behaviour is defined as last-one-wins, so a document carrying two password fields parses cleanly and silently discards one of them. That is a parsing decision hiding inside what looks like an authoring mistake.

The third is number handling. JSON numbers are arbitrary precision on paper, and most language runtimes convert them to a 64-bit float the moment they parse. An integer beyond 2^53 comes back rounded, which matters for identifiers and for any value holding money. Formatting is where I spend more attention than the topic usually gets. The tension is between a stable format, so diffs show real changes, and a compact one, so the payload stays small.

Minified JSON is unreadable and diffs as a single changed line. Pretty-printed JSON is readable and diffs usefully. Choose the readable one and let a compression layer handle size. I also cover the encoding details deciding whether a document is valid at all: UTF-8 with no byte order mark, correct escaping inside strings, and the fact that a bare control character inside a string makes the document invalid.