Machines don't care whether JSON is indented or crammed onto one line — parsing works either way. The cost of unformatted JSON shows up specifically at the moments humans have to interact with it: debugging, code review, and version control. (For the actual syntax rules — valid data types, escaping, the double-quotes requirement — see JSON Formatting Explained: Syntax, Rules, and Common Pitfalls.)
The concrete git diff problem
This is the clearest, most measurable case for formatting. Say you change one value in a JSON config. Minified on one line:
- {"name":"api-config","version":"1.0","timeout":30,"retries":3,"debug":false}
+ {"name":"api-config","version":"1.1","timeout":30,"retries":3,"debug":false}
Git shows the entire line as changed, because the whole file is one line — a reviewer sees "the whole config changed" and has to manually diff the two strings themselves to find what actually moved.
Formatted:
{
"name": "api-config",
- "version": "1.0",
+ "version": "1.1",
"timeout": 30,
"retries": 3,
"debug": false
}
Now the diff shows exactly one line changed. This isn't a readability nicety — it's the difference between a reviewer seeing precisely what changed versus having to re-derive it manually, and it directly affects how thorough code review actually is in practice (a reviewer who has to manually diff a wall of text is more likely to skim and approve than genuinely check).
Where unformatted JSON actually costs time
Debugging a failing API response. A single misplaced comma or wrong data type is nearly invisible in a dense single-line payload; in formatted JSON, indentation makes a structural break (a missing closing brace, an extra nesting level) visually obvious before you even find the specific bad character.
Onboarding and review. A new team member — or a reviewer seeing an unfamiliar config for the first time — reads structure through indentation. Minified JSON removes that visual scaffolding entirely, so understanding the actual data shape requires mentally reconstructing it rather than just looking at it.
Producing consistently formatted JSON programmatically
If you're generating JSON output from code (logs, config files, API responses in development), controlling formatting at generation time avoids the problem entirely rather than reformatting after the fact:
import json
json.dumps(data, indent=2, sort_keys=True)
JSON.stringify(data, null, 2);
A nuance on key sorting
Alphabetically sorting keys (sort_keys=True above) makes large config files easier to scan for a specific known property — useful when you're hunting for one setting in a big file. But it can work against readability for JSON where keys have a logical grouping (e.g., an object where "type" naturally comes first because everything else depends on it). Sorting is a reasonable default for machine-generated config and large flat structures; for hand-authored JSON with a meaningful key order, forcing alphabetical sort can actually remove useful structure rather than add it. Use it as a default, not an absolute rule.
The trailing comma reminder
Worth repeating since it's the single most common formatting-adjacent error: JSON forbids trailing commas after the last element in an object or array, even though it's fine (and common) in JavaScript itself. Formatting tools that auto-fix this catch it before it becomes a parse error at runtime.
Formatting on demand
For a one-off check or cleanup, ToolSink's JSON Formatter validates and reformats pasted JSON instantly, pointing to the specific location of a syntax error if the input is invalid.
Conclusion
Formatting JSON isn't about aesthetics — it's specifically about making git diffs precise, making structural errors visible before runtime, and reducing the cognitive cost of review. The clearest evidence is the diff example above: the actual information content of the change didn't change, only whether a human (or a reviewer) can immediately see it.