JSON formatting: why pretty-printing matters (and how to do it safely)

August 10, 2026·4 min read·Developer Tools

By the Converterzilla Team

We build privacy-first PDF and image tools that run entirely in your browser. Our team has shipped JavaScript file-processing apps used by thousands every day, and we write here about the libraries, trade-offs and patterns we use.

JSON coming back from an API is usually minified — every object, array and string packed onto one line with no whitespace, because whitespace costs bytes on the wire. That's great for a server response and terrible for a human trying to find the one field that's wrong. A JSON formatter (also called a "pretty printer") re-indents the same data with consistent spacing and line breaks so nesting is actually visible.

What formatting does and doesn't change

A correct JSON formatter only changes whitespace — indentation, line breaks, spacing around colons and commas. It never reorders keys, changes types, or drops data. If a formatter "fixes" your JSON by silently removing a field, that's a bug, not a feature. The output should parse back to the exact same JavaScript object as the input.

Formatting vs. validating

These are two different jobs that often get bundled into one tool:

  • Formatting assumes the JSON is already valid and just re-indents it for readability.
  • Validating checks whether the JSON is syntactically correct at all — matched brackets, quoted keys, no trailing commas — and points at exactly where it breaks if it isn't.

If you're debugging a response that won't parse, start with a JSON validator to find the syntax error first. Once it's valid, a JSON formatter makes it readable.

The trailing-comma trap

The single most common reason hand-edited JSON breaks: a trailing comma after the last item in an object or array. JavaScript object literals tolerate this; strict JSON does not. {"a": 1, "b": 2,} is invalid JSON — that final comma before the closing brace will fail every standards-compliant parser, even though it looks harmless.

Minify for production, format for debugging

The two directions aren't in tension — you want both, at different times. Minified JSON in transit and in storage (smaller payloads, less bandwidth); formatted JSON when a human is reading it in a log file, a browser devtools panel, or a bug report. Good tooling should make switching between the two a one-click operation, not a manual re-indent.

A quiet privacy problem

API responses often contain real user data — emails, tokens, internal IDs, sometimes full customer records pulled straight from a database for debugging. Pasting that into a random "free json formatter" website means it's now sitting on that site's server, possibly logged, possibly cached. A formatter that runs entirely in your browser never sends the JSON anywhere — the same page that renders the pretty-printed output is the only place the data ever existed.

Our JSON formatter and JSON validator both work this way: paste, format or validate, done — nothing leaves your browser.

More from Developer Tools