JSON Formatter

Almost every JSON you actually have to read arrives in the worst possible shape: one enormous line copied out of a network tab, a log field, a Kafka message viewer or a curl response. Finding the one field you care about in three thousand characters of unbroken text is a genuinely miserable way to spend a Tuesday. This formatter re-indents the whole structure so the object hierarchy is visible, and when the document does not parse it tells you the exact line and column of the offending character instead of the useless "Unexpected token" that browsers throw.

Parsing uses the browser's native JSON.parse, so the rules applied here are precisely the rules applied by every other conforming JSON reader — RFC 8259, no exceptions carved out. Everything runs in a Web Worker on your own machine, which means a 6 MB API dump will not lock up the page and, more to the point, will never leave your device. That matters when the payload you are debugging contains a customer email address or a bearer token.

What formatting changes, and what it does not

This is not a whitespace-only text transform. The document is parsed into real JavaScript values and re-serialised, which is the only way to guarantee the output is valid JSON rather than plausible-looking text. Re-serialising has a few consequences worth knowing about before you paste the result back into a file:

• Number literals are normalised. 1.0 becomes 1, 1e3 becomes 1000, and 1.20 becomes 1.2. The numeric value is identical; the spelling is not.
• Escaped characters are decoded where they can be. "caf\u00e9" comes back as "café", because both are the same string and UTF-8 output does not need the escape.
• Duplicate keys collapse. JSON permits repeated keys and JSON.parse keeps the last one, so {"a":1,"a":2} formats to a single "a": 2.
• Integer-like keys move to the front. This is a JavaScript object rule, not a JSON one: keys such as "0", "7" and "42" are ordered numerically ahead of all other keys. Every JavaScript-based formatter behaves this way.

Everything else — key order, array order, string content, boolean and null values, nesting — is preserved exactly. If you need a strictly byte-preserving round trip, do not run any parse-and-reprint formatter, including this one.

When sorting keys is the right call

Sorting is applied recursively to every object at every depth, not just the top level, using a locale-aware comparison. The single best reason to use it is diffing. Two services that serialise the same record with different key orders produce diffs that are entirely noise; sort both sides first and the diff collapses to the fields that genuinely differ.

It is also useful for reviewing large configuration blobs, where alphabetical order makes a specific setting findable, and for producing a stable canonical form before hashing or caching a payload.

Leave it off when key order is part of the document's meaning to a reader — an OpenAPI file where summary sensibly precedes parameters, or a fixture whose ordering mirrors the code that produced it. JSON itself defines objects as unordered, so no consumer should ever depend on order for correctness, but humans reading the file certainly do.

Reading the error message

When parsing fails, the message names the fault and gives you a line and a column, derived from the character offset the engine reports. Four causes account for the overwhelming majority of failures: a trailing comma before } or ], single quotes where JSON requires double, an unquoted key, and a // or /* */ comment that JSON simply does not have.

All four are legal in JavaScript object literals and in JSON5, which is exactly why they slip in. If your input is hand-maintained config that has drifted into JSON-with-comments, or output copied out of a chat assistant, the JSON Repair tool will fix all four automatically instead of making you hunt them one at a time.