How to Format and Beautify Minified JSON

You paste an API response into your editor and get a single 22,000-character line. Somewhere in there is the field you need. Scrolling sideways is not a plan.

Formatting JSON — beautifying, pretty-printing, whatever you call it — solves this by adding line breaks and indentation that make the structure visible. It takes about two seconds, and there are half a dozen ways to do it depending on where the JSON is. This post covers each of them, the choices that matter, and the cases where formatting is not what you want. For JSON's rules themselves, The Complete Guide to JSON is the reference.

What formatting actually does

Take a minified object:

{"id":"A-8842","total":129.5,"items":[{"sku":"TSH-01","qty":2}],"paid":true}

Formatted, it becomes:

{
  "id": "A-8842",
  "total": 129.5,
  "items": [
    {
      "sku": "TSH-01",
      "qty": 2
    }
  ],
  "paid": true
}

Same document. JSON treats whitespace between tokens as insignificant, so a parser produces identical results from both. The only whitespace that carries meaning is whitespace inside a string — "New York" keeps both spaces no matter how you indent the surrounding document.

That is why round-tripping is safe. Minify a file, beautify it, and you get semantically identical JSON back. You can automate the transformation without worrying about corrupting data.

Method 1: A browser tool (fastest for one-offs)

For the common case — you have some JSON on your clipboard and want to read it now — paste it into a JSON Formatter. It indents valid JSON immediately and tells you where the parse failed if it is not valid, which means it doubles as a syntax checker for free.

The reason to prefer a client-side formatter specifically: the JSON you most often need to format is a live response from a staging or production API. It contains bearer tokens, email addresses, order records, internal field names. A tool that runs in your browser parses and re-indents locally in JavaScript — nothing is uploaded, nothing is logged server-side, and you can format a payload you would never be allowed to paste into a random web service.

Method 2: In code

Every language ships this. The pattern is always parse-then-serialise-with-indentation.

JavaScript / TypeScript

JSON.stringify(JSON.parse(text), null, 2)

The third argument is the indent. Pass a number for spaces, or the string "\t" for tabs. The null is the replacer argument, which you can use to filter keys.

Python

json.dumps(json.loads(text), indent=2)

Add sort_keys=True if you want deterministic key ordering — handy for diffing two payloads that contain the same data in different orders. Add ensure_ascii=False to keep non-ASCII characters readable rather than escaped to \uXXXX.

Command line

jq . is the standard answer and pretty-prints by default:

cat response.json | jq .

jq -S . sorts keys; jq -c . minifies instead. If jq is not installed, python3 -m json.tool file.json is available almost everywhere.

Method 3: In your editor

VS Code formats JSON natively — Shift+Alt+F on Windows and Linux, Shift+Option+F on macOS. For text pasted into an untitled buffer, set the language mode to JSON first or the formatter has nothing to work with.

Prettier handles .json files as part of a normal repo format-on-save setup, which is the right way to keep committed JSON consistent without anyone thinking about it. JetBrains IDEs use Ctrl+Alt+L / Cmd+Option+L.

Choosing an indent

Two spaces is the practical standard. npm writes package.json with two, Prettier defaults to two, and it keeps deeply nested documents on screen — at four spaces, a six-level-deep config is already 24 columns in before any content appears.

Tabs are defensible for the same accessibility reason they are in code, but they are rare in JSON and mixing them into a repo that uses spaces produces noisy diffs. Whatever you pick, enforce it with a formatter rather than by hand.

When the formatter refuses

A formatter must parse the document before it can indent it, so invalid JSON produces an error instead of output. That is not the tool being unhelpful — it is the fastest signal you will get that something is wrong.

The usual culprits are a trailing comma before a closing brace, single quotes where JSON requires double, unquoted keys copied from a JavaScript literal, a // comment, or an unescaped quote inside a string value. Each one has a characteristic error message; we go through them and their fixes in common JSON syntax errors.

Escaping problems deserve a special mention because they look like formatting problems. When a JSON document has been stringified and embedded inside another JSON document, every quote in the inner payload carries a backslash and the result is genuinely unreadable. Formatting the outer document does not help — you need to unescape the inner string first. The rules are in JSON escape characters explained.

When indentation is not enough

Formatting makes structure visible, but on a 4,000-line response it just gives you 4,000 lines to scroll. Past a certain depth, indentation stops being the right visualisation.

That is where a JSON Tree Viewer earns its place. It renders the document as a collapsible tree, so you can fold the eleven branches you do not care about and expand the one you do. For exploring an unfamiliar API response — working out what fields exist and how a collection is nested — a tree beats indented text every time.

The reverse: when to minify

Formatting is for humans. The moment the consumer is a machine, the whitespace is pure cost.

Minify JSON that goes over the network: API responses, message queue payloads, config embedded in a JavaScript bundle, values written to localStorage, log lines. Whitespace can be 20% or more of a nested document, and while gzip compresses it well, you still pay to generate, transmit, and parse those bytes. A JSON Minifier does this in one step, and it belongs in your build pipeline rather than in a manual workflow.

Keep formatted, on the other hand, anything a person reads or edits: committed config files, test fixtures, documentation examples, seed data. The Git argument alone settles it — a change to one field in a minified file shows up as the entire file having changed.

A workflow that holds up

1. Copy the raw payload from your network tab, log, or clipboard.
2. Paste it into the formatter. If it indents, it is valid; if it errors, you have your bug and its location.
3. Deep document? Switch to the tree viewer and collapse your way to the field you want.
4. Formatting something other than JSON in the same session — a config file, a minified script — a general code beautifier covers the other languages without changing tabs.
5. Shipping it? Minify as a build step, never by hand.

The whole loop takes seconds, and it runs locally, which means you can do it with real production data instead of a sanitised sample that does not reproduce the bug.