JSON Formatter

JSON ended up as the format for nearly everything: API responses, configuration files, package manifests, log lines, database columns, CI definitions. That ubiquity is why formatting comes up so often — the data is designed to be compact in transit, and every time you need to read it as a human you need it expanded. The moments you reach for a formatter are consistently the same: an API returned something unexpected, a config is not taking effect, a log line contains a nested payload, or you need to see whether a field you expected is actually there.

The most frequent source of confusion is assuming that anything valid in a JavaScript object literal is valid JSON. It is not. JSON has no comments, no trailing commas, no single-quoted strings, no unquoted keys, no undefined, and no functions. Numbers cannot be NaN or Infinity, and keys must be strings. That strictness is deliberate — it is what makes JSON parseable identically everywhere — but it means a config file that looks perfectly reasonable to a JavaScript developer can be rejected outright by a JSON parser.

Because JSON as transmitted is optimised for machines, not for reading. An API response arrives as one continuous line where a nested object three levels down is genuinely impossible to follow, and where you cannot tell whether a field is missing or you simply have not found it. Indenting the structure makes the shape visible: you can see which keys belong to which object, how deep the nesting goes, and where an array ends. Formatting never changes the data — only the whitespace between tokens, which JSON parsers ignore.

Usually one of four things, all of which JSON forbids even though JavaScript allows them: a trailing comma after the last item, single quotes instead of double quotes, unquoted keys, or a comment. JSON is a deliberately strict subset — no comments, no trailing commas, keys always double-quoted. If the file came from a config or was hand-edited, that is almost certainly the cause, and the Repair tool fixes exactly these cases automatically.

It removes every key whose value is null, which is a common way to trim a verbose API response down to the fields that carry information. Use it with care, because it changes the data rather than just its formatting: in many APIs null is meaningful — it can mean "explicitly cleared" as opposed to "not provided", and a PATCH request that omits a field usually behaves differently from one that sends it as null. Fine for reading; think twice before sending the result anywhere.

Files up to a few megabytes format quickly. Beyond that you are limited by the fact that everything happens in a browser tab: the whole document is parsed into memory and re-serialised, and the editor has to render the result. For genuinely large data, command-line tools are the right answer — jq will format, filter, and query multi-gigabyte files without loading them whole, and it is worth learning for anything you do repeatedly.

No. Every tool runs in your browser as JavaScript — your data is never uploaded, never logged, and never sent to a server. You can confirm it by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and seeing that everything still functions. That matters for JSON in particular, because API responses routinely contain personal data, tokens, and internal identifiers.