How to Format JSON: A Visual Guide for Humans and Machines

JSON is the format everyone uses and almost nobody formats. APIs return it minified to save bytes, logs print it on a single line to fit the terminal, and config files somehow end up with three different indentation styles in the same project. The good news is that JSON formatting is a solved problem — you just need the right tool and a few rules.

What "formatting JSON" actually means

JSON is whitespace-insensitive. That means {"a":1,"b":2} and the multi-line, indented version are the same data. Formatting is the process of adding whitespace back in to make the structure legible to humans, without changing a single byte of meaning. A JSON formatter does the inverse of minification: it takes the single-line version and turns it into something you can actually read.

A typical formatter gives you control over:

• Indentation — 2 spaces is the de-facto standard (it's what JSON.stringify(obj, null, 2) uses in JavaScript), but 4 spaces and tabs are common. Pick one and stick to it.
• Key sorting — useful for diffs. If your keys are sorted alphabetically, two semantically identical objects produce identical text, and Git stops complaining.
• Trailing comma handling — JSON itself does not allow trailing commas, but JSON5 and most parsers tolerate them. A good formatter will either preserve or strip them consistently.

Pretty vs. minified: when to use which

Use pretty-printed JSON when humans are reading it: in source files, in documentation, in commit messages when you absolutely must paste a payload. Use minified JSON when bytes matter: API responses on the wire, storage in a wide-column database, or anything that gets gzipped and shipped over HTTP. The data is identical; the trade-off is human legibility vs. file size.

A useful workflow: keep your source-of-truth files pretty-printed (with 2-space indentation and sorted keys), and let your build pipeline minify them on the way out. That way humans and machines are both happy.

Common JSON mistakes (and how to spot them)

A JSON validator is more than a "does it parse" check — it tells you where the parser gave up. Here are the mistakes that account for 90% of broken JSON you'll see in the wild.

1. Single quotes instead of double quotes

{ 'name': 'Alice' }   // ❌ Invalid
{ "name": "Alice" }   // ✅ Valid

JSON requires double quotes for strings and keys. Single quotes are a JavaScript object literal, not JSON, even though JSON.parse in V8 will sometimes accept them with a warning. Don't rely on that — fix the source.

2. Trailing commas

{
  "a": 1,
  "b": 2,    // ❌ Trailing comma — invalid JSON
}

Many languages tolerate trailing commas in arrays and objects, but JSON does not. If you're authoring JSON by hand (in a config file, say), the easiest fix is to format the file with a tool that auto-strips them, then paste the result back.

3. Unquoted keys

{ name: "Alice" }    // ❌ Invalid
{ "name": "Alice" }  // ✅ Valid

Another JavaScript-ism. JSON keys are always strings, and strings are always double-quoted.

4. Comments

JSON does not support comments. If you're tempted to add // TODO to a config file, use JSON5, YAML, or TOML. If you must stay in JSON-land, use a key like "_comment": "...".

5. Numbers and NaN

JSON numbers cannot be NaN, Infinity, or hex. They cannot have leading zeros (so 007 is illegal). They can be integers or decimals; if you need arbitrary precision, you're out of luck — pass them as strings.

JSON vs. JSON5 vs. JSONC

You will see three flavors in the wild:

• JSON — the strict spec, as defined in RFC 8259. No comments, no trailing commas, double quotes only.
• JSON5 — a superset that adds comments, trailing commas, single quotes, and unquoted keys. Used by some config files (e.g. .eslintrc, before ESLint moved to flat config).
• JSONC — "JSON with comments", used by VS Code's settings.json and a few other tools. Comments and trailing commas allowed, otherwise strict JSON.

A general-purpose JSON formatter targets strict JSON. If you need JSON5 or JSONC support, you want a tool that explicitly says so.

JSON in a wider workflow

JSON is rarely the end of the road. Common next steps:

• Convert JSON to YAML when you're moving from an API response into a Kubernetes manifest, a GitHub Actions workflow, or a Docker Compose file.
• Convert JSON to CSV when you're loading an API response into a spreadsheet. (Note: this only works cleanly for arrays of flat objects; nested JSON needs flattening first.)
• Wrap JSON in JSON-LD when you want search engines to read it as structured data.
• Decode a JWT when the JSON is a JSON Web Token, and you want to inspect the claims without verifying the signature.

What to look for in a JSON formatter

Not all formatters are equal. The good ones:

1. Highlight errors with line and column numbers — not just "parse error", but "line 12, column 4: unexpected token".
2. Run entirely in the browser — your JSON never leaves the page. Critical when the JSON contains secrets, PII, or production data.
3. Handle large files gracefully — anything under a few MB should format in under a second, with the UI staying responsive.
4. Offer minify, pretty-print, and key sort in one click, not three different tools.
5. Tolerate JSON5 and JSONC if you live in config files.

Try it

Uttir's JSON formatter and JSON validator are designed to do exactly this — paste, format, sort, minify, all in your browser, nothing uploaded. Open DevTools, watch the Network tab, and confirm for yourself: zero outbound requests after the page loads.