JSON Formatter — When Pretty Print Saves You From Production Fire

The API returned HTTP 200. The mobile app crashed on launch. The shared fixture in the repo was one giant minified line someone “cleaned up” by hand. Buried inside was a duplicate key. Some parsers keep the first value; others keep the last. Pretty-printing would not have invented validity — but it would have made the duplicate obvious in review.

A JSON formatter is a microscope, not a healer. Invalid JSON stays invalid. What formatting gives you is structure you can diff, grep, and reason about under pressure.

A workflow that beats panic scrolling

1. Validate with a strict parser (JSON.parse, jq empty, language decoder).
2. Format with stable indentation (2 spaces is fine; pick one).
3. Diff against a known-good sample from staging.
4. Only then chase business-logic bugs.

jq empty payload.json          # fail fast if invalid
jq . payload.json > pretty.json
diff -u golden.json pretty.json

In the browser, paste into a JSON formatter when the payload is sitting in a Slack thread and you do not want to drop it into a random “upload your file” site. Prefer local-only tools for anything that might contain PII or tokens — redact first when unsure.

Myths that waste an on-call night

“Pretty print fixes invalid JSON.”
Trailing commas, single quotes, and NaN are still errors. Some editors “JSON with Comments” parse for convenience; production JSON.parse will not.

“Key order in JSON.stringify is the API contract.”
ECMA-404 objects are unordered; many serializers preserve insertion order as a courtesy. Never assert byte-identical object key order across languages unless you have an explicit canonicalization step.

“Duplicate keys are fine.”
RFC 8259 says names should be unique. Behavior with duplicates is a parser lottery. Formatters that parse then re-serialize may drop a duplicate silently — which is both helpful and dangerous. If your tool collapses keys, compare against the raw text too.

What to look for once it is readable

Smell	Why it hurts
Mixed id types (string vs number)	Client decoders disagree
null vs missing key	Optional handling forks
Huge nested arrays inline	Hard to spot truncated responses
Numbers as 64-bit ints	JS loses precision above 2^53-1
Base64 blobs inlined	Masks structure; consider separate fields

When JS is in the path, watch large integers (snowflake IDs). Pretty printers still show them as numbers; the bug appears after parse. Quote IDs as strings in JSON APIs if clients are browser-based.

Formatting in CI without noise

Format committed fixtures so diffs are line-oriented. Do not re-format live traffic logs in git. For golden files:

jq -S . fixture.json > fixture.json.tmp && mv fixture.json.tmp fixture.json

-S sorts keys — useful for stable diffs, wrong if you are testing order-sensitive code (rare; usually a smell).

FAQ

Why does my formatter say valid but Jackson throws?
Features like comments, unquoted keys, or leading zeros differ by library. Match the parser your service actually uses.

Should production logs be pretty-printed?
Usually no — use structured single-line JSON for logs. Pretty print when humans debug a captured body.

Is minified JSON faster for clients?
Marginally smaller on the wire; HTTP compression dominates. Prefer clarity in fixtures and readability when debugging.

Validate, format, diff. Pretty print will not resurrect broken JSON — but it will stop you from shipping a duplicate-key landmine disguised as one long line.