Minify vs pretty-print

By Bruno J F Costa · Same data, different jobs: reading, shipping, and reviewing diffs.

Pretty-printing adds whitespace so humans can see structure. Minifying (compact output) removes insignificant whitespace so the payload is smaller or fits in one line. Neither operation should change numbers, strings, or key names. If a tool “minifies” by dropping properties or reordering with a different meaning, it is not a formatter — it is a transform. JSON Quiet treats indentation as print style only.

The homepage explains how to click Format. This page is about when to choose compact versus 2- or 4-space output, and what you will regret if you pick the wrong one for the job.

Pretty-print when you must read

Use 2 or 4 spaces (or the site default of 3) when you are inspecting an API body, writing a ticket, or comparing two responses by eye. Nested objects become a tree. Missing commas and mismatched braces are easier to see after a successful format. If Format fails, the document is not valid JSON yet — fix syntax first, as in the validation guide.

Pretty-printed fixtures also make code review possible. A one-line 40 KB fixture in git is hostile. A formatted fixture diffs as “this field changed,” which is the point of storing JSON in a repo.

Compact when the consumer wants one line

Choose compact when you will paste into a constrained field: some admin UIs, query-string experiments, or log lines that expect a single JSON value with no raw newlines. Compact is also what many production APIs emit. That is not a quality judgment. Servers minify to save bytes; you pretty-print locally to understand them, then compact again if you must echo the same shape back.

Do not compact as a “security” step. Removing whitespace does not hide secrets. If the document contains a token, compacting it still contains the token. See what not to paste.

Diffs, keys, and false changes

Switching from 2 spaces to 4 spaces rewrites every line. Git will show a huge diff with no data change. Agree on one style per repository. If you must re-indent a committed file, do that in its own commit so reviewers can ignore it.

Key order is a separate issue. RFC 8259 does not give object members a meaningful order, but many formatters preserve the order they parsed. JSON Quiet prints keys in the order the parser produced. Do not rely on key order as API contract unless your stack documents it (some systems do).

A practical loop

Paste the production (often compact) body into the editor.
Format with 2 or 4 spaces. Read. Validate in strict mode.
Edit if you are building a fixture. Validate again.
If the next hop needs one line, switch Options to compact and Format once more.
Copy. Do not keep both versions as “source of truth” unless one is clearly the repo file and the other is a throwaway paste.

Size is rarely the bottleneck you think

For documents under a few hundred kilobytes, indentation is cheap compared with network latency and your time. Minify because a consumer requires it, or because you embed JSON inside another string and newlines would break the wrapper — not because “smaller looks more professional.” Gzip on the wire already shrinks repeated spaces.

Very large documents (multi-megabyte GeoJSON, huge dumps) can make a browser editor sluggish. Expand the editor for room, or work on a slice. A formatter is not a substitute for streaming tools when the file does not fit comfortably in memory.