How to Format JSON

The document is parsed and re-serialised locally — no upload, which matters because the JSON you most need to read is usually an API response with a token or a customer record in it.

This is the part most formatter pages skip. Formatting is not a cosmetic pass over the text — the document is parsed into a structure and a new document is written from that structure. Four things can differ between what you pasted and what you get back.

Duplicate keys collapse. A document containing the same key twice is legal JSON, and the parse keeps only one of them, so {"a": 1, "a": 2} formats to a single member. Data disappears, silently, and the output looks perfectly clean.

Numbers are normalised. 1.0 becomes 1, 1e3 becomes 1000, and -0 becomes 0. The value is the same as far as the format is concerned, because JSON has one number type; the text is not. And a number with more than about fifteen significant digits comes back rounded, which is the one case where formatting genuinely loses information.

Key order follows the parser. Members come out in whatever order the parser exposed, not necessarily the order you wrote. In practice JavaScript preserves insertion order for string keys, so this rarely surprises anyone — but it is not a guarantee the format makes.

Anything that was not JSON is gone. Comments, trailing commas and single quotes cannot survive a round trip, because the parse rejects them outright rather than tolerating them.

For a configuration file you are about to commit, that mostly means the formatted output is better than what you had. For a document you intend to compare byte-for-byte with something else, it means format both sides or neither.

The formatter here always indents with two spaces. That is not a missing feature so much as a deliberate absence of a decision — two spaces is what JSON.stringify(value, null, 2) produces, and it is the convention almost every JSON file in the wild follows, including package.json and tsconfig.json.

Where the convention differs:

If you need four spaces or tabs, the stringify tool exposes the spacing directly. In code, the third argument to JSON.stringify takes either a number of spaces or a literal string, so passing a tab character indents with tabs.

One thing indentation cannot fix is width. Deeply nested JSON becomes unreadable through sheer indentation before it becomes unreadable through lack of it, which is what the tree view is for.

Minifying strips every byte of insignificant whitespace. On a heavily indented document it typically removes 15–30% of the characters — real, but less impressive than it sounds, because the actual answer to payload size is compression.

Gzip and Brotli are extremely good at repetitive whitespace. Once a response is compressed in transit, the difference between formatted and minified JSON is small, so if your server sets Content-Encoding correctly, minifying by hand is not where your bandwidth savings live.

Cases where minifying is genuinely worth doing:

• Embedding JSON in something else — a data attribute, an environment variable, a URL parameter — where every character counts and newlines are awkward.
• Storage at volume, where you are paying per byte and the same structure repeats millions of times.
• A payload that is not compressed in transit, which is more common than it should be on internal services.

And the case against: never store minified JSON in version control if a human will ever have to review a change to it. A one-line file makes every diff the entire file, which is exactly the problem structural comparison exists to solve.

A formatter cannot format what it cannot parse, so an error here is a syntax error rather than a formatting failure. The message you get is the parser's own — something like Unexpected token } in JSON at position 412 — and the tool turns that character position into a line number.

Two shortcuts before you go hunting by eye:

Try the repair. The Fix button handles the four mistakes that account for most hand-written failures: single-quoted strings, unquoted keys, trailing commas, and a missing comma between adjacent objects or arrays. It is deliberately string-aware, so a URL like "http://example.com" or a time like "12:30" is left alone rather than being mangled by a global regex — the tool page explains the boundary of what it will touch.

Read the position, not the line. The character offset is exact; the line number is derived from it. If the message points at position 412 and your document is one long line, the line number will say 1 and the offset is the only useful information.

Every error message and its cause covers the rest, including the ones the repair cannot fix.