Precise JSON prettifier

The operation this JSON prettifier performs is narrow and worth stating precisely: the input is parsed into a value, and that value is serialised back out with two spaces of indentation per nesting level. Parse, then serialise. Nothing else happens in between.

Everything that follows is a consequence of that definition. The transformation is lossless with respect to the data, because the data is reconstructed from a parsed representation rather than edited as text. It is also strict, because a parse either succeeds or it does not. And it is local: the parse and the serialise both execute in the browser, so the input is never transmitted, which in turn means there is no run limit and no length cap to enforce.

No configuration, because there is nothing configurable.

Step 1

Paste the JSON into the input field, in whatever state it currently carries.

Step 2

Press Format. The parse and reindent run client side and return immediately.

Step 3

Copy the reformatted result from the output panel.

Rejection is binary. The parser either accepts the text as JSON or it returns a failure, and the failure carries no line number and no column. That is a real limitation of this surface and it is worth stating rather than glossing: some competing formatters do report an exact position, and on a very large document that is genuinely more convenient.

What can be offered instead is the causal list, which in practice narrows the search quickly, because the population of ways valid-looking text fails to be JSON is small and heavily skewed toward a few culprits.

Trailing comma

Permitted by JavaScript object and array literals, prohibited by the JSON grammar.

Single-quoted strings

The JSON grammar admits only double quotes, for both keys and string values.

Unquoted keys

A bare identifier as a key marks the text as a JavaScript literal rather than JSON.

Comments

JSON has no comment production. Text that carries them is JSONC or JSON5, not JSON.

Non-finite numbers

NaN and Infinity have no JSON representation, and neither does undefined.

Surrounding context

A log prefix, a shell prompt or an unbalanced bracket captured with the payload.

Line-based diff algorithms, which is to say the ones git and every review platform built on it use, treat the line as the atomic unit of change. A minified JSON file occupies one line, so any modification to any field marks that single line as changed, and the diff conveys no information beyond the fact that something moved.

Serialised across many lines with one key per line, the same modification produces a minimal diff isolating exactly the changed entry. This asymmetry is the reason committed JSON fixtures and configuration are conventionally stored indented despite the storage cost: the bytes saved by minification are negligible, and the review cost imposed by it is not.

The serialiser is called with an indent of two, unconditionally. There is no selector for four spaces or tabs, which is a deliberate narrowing rather than an omission to be apologetic about, but it is still a constraint worth knowing before you rely on the output.

Two is the prevailing convention in the JavaScript and TypeScript ecosystems, where most JSON is produced and consumed, and it has a structural advantage: indentation cost grows linearly with depth, so at four spaces a six-level structure begins at column twenty-four and pushes long string values past a typical line width. If a project standardises on something else, the editor's own formatter applies it in one further step.

Reindenting changes whitespace and nothing else. It does not sort keys alphabetically, since the serialised order follows the parsed insertion order. It does not validate against a schema. It does not attempt repair, so malformed input is returned as a failure rather than as a best guess.

It also cannot catch a semantic error, and the distinction matters. A date stored as a string where a number was expected, an omitted required field, a typo inside a key name that remains syntactically valid: all of these format cleanly, because all of them are valid JSON. The only property confirmed by a successful format is that the input parses.

No. Readability and correctness are orthogonal properties, and conflating them is the most common misreading of what a formatter provides. A perfectly indented document can carry entirely wrong values.

The defensible claim is narrower and still useful: formatting produces a surface on which a human reviewer can detect errors that a minified surface conceals. The detection remains the reviewer's work. The tool supplies the surface.

Engineers inspecting an API response mid-investigation, where the question is the shape of the returned data rather than its formatting. Reviewers normalising a fixture before it enters version control, trading a one-off step now for legible diffs indefinitely.

Support and QA staff reading a raw payload lifted from a bug report or a log line, and analysts handed an export with no tooling and told the answer is somewhere inside it. The common thread is that the data has to be read by a person before it can be acted on.