A failed API call almost always hands you one compressed, unreadable line of JSON and an error code that isn't specific enough to act on. Before assuming the API itself is broken, it's worth ten seconds of formatting to see what actually came back — most "the API is down" reports turn out to be a malformed request that produced a perfectly valid error response.
The four errors that show up constantly
Trailing commas after the last item in an array or object — valid in JavaScript object literals, invalid in strict JSON, and the single most common copy-paste error from editing JS by hand. Unquoted or single-quoted keys, again a JS habit that doesn't carry over. Unescaped quotes inside a string value, usually from a user-submitted field with an apostrophe that never got escaped server-side. And mismatched brackets from a response that got truncated mid-stream — if the error is at the very last character, truncation is the first thing to check, not a syntax mistake.
What formatting won't tell you
A formatter validates syntax, not meaning. JSON that parses cleanly can still be missing a field your code expects, or return a string where you coded for a number. Once the syntax check passes, compare the actual keys and types against whatever schema or documentation the API provides — the formatter's job is done at that point, and a second, different kind of bug is what's left.
Before you paste anything into a formatter
If the response includes an auth token, a session ID, or a real user's data, don't paste it into a tool you haven't checked the network behavior of. A formatter that sends your input to a server for processing has, by definition, already transmitted whatever you pasted — checking the browser's network tab for outgoing requests while you use it takes fifteen seconds and settles the question. Tools that process entirely client-side make no request at all, which you can confirm the same way.
A repeatable checklist
Format first to catch syntax errors. Check the last character if the error position is at the end of the string — that's almost always truncation. Diff the key names against documentation, not against memory. And if you're debugging the same malformed response repeatedly, fix it at the source rather than reformatting it by hand each time; a formatter is for understanding a one-off problem, not a workaround for a server that consistently returns broken output.