JSON formatter

The cheap way to build a formatter is to walk the characters and add a newline after every brace and comma. It is fifty lines, it works on most input, and it fails on the one case that matters: a brace, a bracket or a comma inside a string value. A URL with a query string, a regular expression stored as a setting, a message containing a comma — any of those and the output is no longer valid JSON.

This one runs the document through a real parser and prints the result. The consequence is that anything it hands back is guaranteed to parse, and anything it refuses genuinely does not — there is no third state where a tool half-understood the input and produced something that looks right.

Parsing and reprinting is not free of consequences, and a tool that did not say so would be hiding them. Numbers are re-rendered in their shortest exact form, so `1.0` becomes `1` and `1e3` becomes `1000`. Duplicate keys collapse to the last one, because that is what every JSON parser does with them. Escaped characters that did not need escaping lose their backslash.

None of that changes what the document means to a parser, which is why it is acceptable. If you need the bytes preserved exactly — you are signing the document, or comparing a checksum — do not format it at all, because any formatter that reindents has already changed the bytes.

Two systems that serialise the same object often emit its keys in different orders, and the resulting diff is the size of the file — which makes reviewing a genuine one-field change impossible. Sorting both sides first collapses that to the change itself.

Arrays are deliberately left alone. An object is unordered by definition and reordering its keys changes nothing; an array is a sequence, and sorting one changes the data. Tools that sort both exist and they will silently reorder a list of steps, a list of coordinates or a list of migrations.

Two spaces is the convention for JSON in most ecosystems and is what `npm`, `composer` and most linters produce. Four turns up in Python-adjacent projects, since it matches the language. A tab is right where a file will be read in editors with different preferences, since the reader decides how wide it is.

The one place it is not a preference is a repository with a formatter already configured. Match it — a file reformatted with a different indent produces a diff touching every line, which costs a reviewer far more than the indent was ever worth.

A file with `//` in it is not JSON, and neither is one with a trailing comma. Both are JSON5 or JSONC, which are different languages that happen to look similar, and both are widely used in configuration files — `tsconfig.json` is JSONC, which surprises people who try to parse it with a strict parser.

This page rejects them rather than tidying them away, and that is the useful behaviour: it tells you that the thing you are holding will not parse where you are about to send it. A formatter that stripped comments silently would hand you a file that works and a mental model that does not.

JSON numbers become doubles, and a double holds integers exactly only up to about nine quadrillion. Past that, an identifier is rounded — a Snowflake id, an old Twitter status id, some database primary keys. `12345678901234567890` comes back as `12345678901234567000`, and nothing in the output says so.

This page notices and tells you, which is the most it can do. The fix is upstream: systems that emit identifiers past that limit send them as strings for exactly this reason, and if yours does not, formatting the document is not the step where you can repair it.