Most JSON debugging time isn't spent understanding the data — it's spent fighting the formatting. A response logged as one unbroken line, escaped quotes from a proxy that double-encoded the body, or a diff against yesterday's payload that's unreadable because the key order changed. None of that is really about the bug you're chasing.
The first habit worth building is pretty-printing before you read, not while you read. Skimming minified JSON to find a nesting level is slower than your eyes think it is. Reformat first, then scan.
The second is unescaping before comparing two payloads. A string that's been through `JSON.stringify` twice — common when a webhook body gets logged as a string field inside another JSON object — looks like noise until it's unescaped once.
The third is validating structure separately from validating values. A parse error and a wrong value produce the same instinct — stare harder at the payload — but they need different fixes. Confirm it parses first, then worry about whether the values are right.
The last two are smaller: minify before pasting into a bug report so reviewers aren't scrolling past whitespace, and keep a scratch tab open for exactly this — the JSON Formatter here does pretty-print, minify, validate and unescape without sending the payload anywhere, which matters when the response you're debugging has real customer data in it.
More from the blog
What We're Building Next: dont-break-prod
A PR-review training game for payments engineers — read the contract, read the code, decide if it's safe to ship.
SQL Formatting Conventions That Make Code Review Easier
A query that's easy to review is one where the diff shows the actual change, not a reflow of every line around it.
Testing Webhooks Locally Without Exposing Your Machine
You don't need to punch a hole in your firewall to see what a provider actually sends before your endpoint touches it.