JSON Formatter

What formatting actually does to your JSON

Beautifying is not a text operation, and that distinction matters more than it sounds. The tool does not add spaces to your string. It parses the string into a data structure, then serialises that structure back out with an indentation setting applied. A parser sits in the middle.

Three useful consequences follow. First, formatting is a validity check in disguise: if the document has a trailing comma or an unquoted key, the parse fails and you get an error instead of mangled output. Second, key order is preserved — modern parsers keep insertion order, so formatting will not quietly alphabetise your fields. Third, whitespace that sits inside a string value is left completely alone, because at that point it is data, not layout.

The one thing formatting cannot fix is a document that was never valid. It will not repair single quotes into double quotes, and it will not strip comments. For that, the JSON Validator tells you exactly which rule was broken so you can correct it yourself.

Choosing an indent width

Indent width is a team convention, not a technical decision, and the only real cost of getting it wrong is diff noise when someone reformats the file. The values this tool offers cover essentially every established style:

• 2 spaces — the JavaScript and Node default, and what JSON.stringify(value, null, 2) produces.
• 4 spaces — common in Java, PHP and C# projects, and the default in many enterprise configuration repos.
• 1 space — used by some tools to keep deeply nested documents from marching off the right edge of the screen.
• 8 spaces — rare, but it appears in a few legacy configuration formats where tab stops were historically eight columns.

If you are formatting a file that already lives in a repository, match whatever the surrounding files use. A formatter that disagrees with the rest of the project turns every future edit into a whole-file diff.

When to minify instead

Minifying strips only the whitespace that sits between tokens. No key is renamed, no value is rounded, no ordering changes — the data is byte-identical once parsed, just smaller on disk.

It is worth being precise about when that helps, because the advice is widely overstated. If your JSON travels over a connection that already uses gzip or Brotli, minifying saves very little: both algorithms collapse runs of repeated spaces extremely efficiently, so a formatted document and a minified one arrive at nearly the same compressed size. Where minification genuinely earns its place is when compression is unavailable or when the file is stored rather than sent.

Three cases where it matters:

• Compiled artefacts and bundles, where a formatting difference of a few hundred kilobytes is paid by every visitor.
• Files written to disk — fixture data, seed files, snapshots — where the saving is permanent rather than per-request.
• Log lines, where one record per line is the whole point and a pretty-printed document would break the format.

For the detailed maths on how much a given payload shrinks, the JSON Minifier reports the before size, the after size and the percentage saved.

Four JSON errors that account for most failures

JSON has a strict grammar, and most of what people call "JSON problems" comes down to habits carried over from JavaScript object literals. These four cover the overwhelming majority of parse failures:

• A trailing comma. {"a":1,} is valid JavaScript and invalid JSON. The parser reports an error at the closing brace, not at the comma, so the message can look one character late.
• Single quotes. {"name":'Ada'} is rejected. JSON strings must use double quotes, on both keys and values, without exception.
• Comments. JSON has no comment syntax. Configure files that allow // are usually JSON5 or JSONC, formats which look almost identical and are not interchangeable.
• Unescaped control characters. A literal newline or tab inside a string is illegal; it must be written as \n or \t. This is the usual cause when a paste from a spreadsheet or a chat message fails.

A fifth problem is not an error at all but looks like one: the input is a JavaScript object printed by console.log, which renders nested objects with single quotes and may abbreviate deep values. Check the source format before assuming the JSON is broken.

Working with large documents

Because processing is local, the limit is your device memory rather than a server timeout or an upload cap. Files of a few megabytes format in well under a second on modern hardware. Beyond that, the browser tab itself becomes the bottleneck, and the practical ceiling depends on how much RAM is free.

Two things help with very large inputs. Format first, then navigate using your editor search rather than scrolling, because a formatted multi-megabyte document is still a multi-megabyte DOM node. And if you only need to inspect the structure rather than edit the text, the JSON Viewer builds a collapsible tree instead of a flat block, which is far easier to navigate when the document has thousands of nodes.