How to format JSON

A JSON error reports the first position where the document stopped being valid, not necessarily where the mistake is. Those are usually the same place, but the important exception is a missing closing bracket or brace: the parser happily continues to the end of the file looking for it, so the error lands on the last line even though the real problem is wherever the structure was left open.

When the reported line looks fine, read the error as "everything up to here parsed, and then the document ran out". Then look for the unclosed structure above it. Formatting the part that does parse is often enough to make the missing bracket obvious, because the indentation will not return to the left margin where you expect it to.

The other common surprise is a trailing comma. JSON does not allow one, though almost every language that reads JSON does allow it in its own object literals, so the habit is easy to carry over. The error appears at the closing bracket rather than at the comma, since a comma is legal right up until it turns out nothing follows it.

Two spaces is the prevailing convention and the one to pick if there is no reason to do otherwise. It is what npm, most linters and most code formatters produce, so it minimises diff noise when a file is shared.

Four spaces reads more clearly for shallow documents but wastes horizontal space quickly once nesting passes three or four levels, which is common in API responses. Tabs let each reader choose their own width, which is genuinely useful for accessibility, but not every tool renders them identically.

Minifying, removing all optional whitespace, is a different goal. It is worth doing for data being transmitted or stored, where the saving is real, and worth avoiding for anything a person is expected to read or a version control system is expected to diff.

JSON object keys are unordered by specification: two documents with the same keys in a different order represent the same object. In practice order is preserved by almost every parser and serialiser, and people rely on it, so sorting is a visible change even though it is not a semantic one.

Sorting is most useful before comparing two documents. Two API responses that differ only in key order will produce a large, meaningless diff; sorting both first reduces it to the differences that matter.

It is worth being careful with configuration files, where a human-chosen order often carries meaning, the important settings first, related settings grouped. Alphabetising that is technically lossless and practically a regression.

RFC 8259 recommends unique names within an object and warns that implementations handle duplicates differently. JavaScript JSON.parse keeps the last value. This formatter therefore discards earlier duplicate members without a duplicate warning; other parsers may reject them instead.

Check the original source with the JSON Validator before formatting. Its duplicate-key scan catches ordinary repeated names in the same object, but escaped names can cause missed matches or false positives. Inspect the source and use a strict decoded-key validator when uniqueness is a security requirement.

These browser tools parse JSON numbers into JavaScript IEEE 754 doubles. Not every integer beyond the safe-integer limit of 9,007,199,254,740,991 is representable; high-precision decimals can round too. Other JSON implementations can use different numeric representations, so this is an implementation limit rather than a rule of JSON syntax.

For example, 9007199254740993 becomes 9007199254740992 after JavaScript parsing. A formatter that preserves numeric tokens or uses arbitrary-precision values can behave differently, but this formatter cannot restore digits already lost during parsing. Send exact identifiers as strings or use a precision-preserving workflow.