How to Read JSON Without Losing Your Mind
September 29, 2026 · 6 min read
You're debugging an API. You open the network tab, click the response, and get this:
{"status":"ok","data":{"users":[{"id":1,"name":"Ada","roles":["admin","editor"],"last_login":"2026-09-28T14:02:11Z","prefs":{"theme":"dark","notifications":{"email":true,"push":false}}},{"id":2,"name":"Bo","roles":["viewer"],"last_login":null,"prefs":{"theme":"light","notifications":{"email":false,"push":false}}}]},"meta":{"page":1,"per_page":50,"total":2}}
One line. No breathing room. Somewhere in there is the field you need, and your eyes are already glazing over. Every developer has been here. The fix takes ten seconds once you know the moves.
Step one: pretty-print it
Minified JSON — everything on one line — is how machines like it. Humans like indentation. A formatter takes that wall of text and expands it into nested, indented structure where you can actually see what's inside what. This single step solves maybe 70% of "I can't read this response" problems.
Paste the response into a JSON formatter, hit format, and suddenly the structure is obvious: there's a data object, it has a users array with two entries, each user has prefs, and so on. The bug you're hunting — a missing field, a null where you expected a string — jumps out once the nesting is visible.
The usual suspects: why your JSON won't parse
Sometimes the problem isn't readability — the JSON is actually broken. Here are the offenders I see over and over:
- Trailing commas.
{"a": 1,}— that comma after1kills it. JavaScript objects allow trailing commas; JSON does not. This is the #1 culprit when hand-writing JSON. - Single quotes.
{'a': 1}looks fine if you write a lot of Python or JS, but JSON demands double quotes. Every key, every string. - Unquoted keys.
{a: 1}is valid JavaScript, invalid JSON. Keys must be quoted. - Comments. JSON has no comments. If your "JSON" contains
//or/* */, it's actually JSONC or JSON5 — fine in config files that support it, fatal to a strict parser. undefinedand functions.JSON.stringify({a: undefined})silently drops the key. If a field vanishes between your code and the wire, check forundefinedvalues.- Copy-paste damage. Smart quotes (
""instead of"") from Word or Slack, invisible zero-width characters, a BOM at the start of the file. When the error position makes no sense, suspect invisible characters.
A good validator doesn't just say "invalid" — it tells you where. "Unexpected token at position 142" plus a formatted view usually gets you to the culprit in seconds.
Reading nested structures strategically
For big responses, don't read top to bottom. Collapse what you don't need (most formatters and browser devtools let you fold nodes) and drill into the branch you care about. I usually search for the field name first (Ctrl+F for last_login), then expand upward to understand its context. It's faster than scrolling through 2,000 lines of user objects when you only care about pagination metadata.
Also worth knowing: null, "", [], and a missing key are four different things. "last_login": null means "we know, and the answer is nothing." A missing last_login key means "we didn't even consider the question." APIs are inconsistent about this, and the distinction matters when you're writing the frontend code that consumes it.
When to minify
Pretty-printing is for humans; minifying is for machines. Strip all the whitespace when you're pasting JSON into a URL parameter, embedding it in a single-line config, or trying to shrink payload size. The content is identical — only the whitespace changes. Just don't try to debug the minified version. Format, fix, then minify. In that order.
A habit that pays off
Whenever an API response confuses you, format it before doing anything else. I've watched people (myself included) stare at minified JSON for ten minutes trying to spot a problem that became obvious three seconds after formatting. It's the cheapest debugging step there is.