How to Format JSON When Debugging API Responses

The first time you inspect a real API response in a network tab or a terminal, it usually looks like a single 2,000-character line: objects nested inside objects, no line breaks, no indentation. That's not a bug in your code — it's minified JSON, which servers send to save bandwidth. Before you can read the data, you need to format it: expand it into indented lines so each object, key, and value is visible.

What formatting actually does

Formatting (also called beautifying or pretty-printing) adds whitespace only — it changes nothing about the data itself. A formatter parses the JSON into a structure, then re-serializes it with indentation. Because it's a pure visual transformation, you can format and minify back and forth indefinitely without losing information. The one thing a formatter cannot do is fix invalid JSON: if the payload has a syntax error, there is nothing to parse, and formatting will only tell you where the error is.

A real example

Here is what a typical API response looks like straight off the wire:

• Raw: {"user":{"id":42,"name":"Ada","roles":["admin","billing"]},"meta":{"page":1,"total":137}}
• Formatted: the same data with each key on its own line, nested objects indented, and arrays split item-by-item so you can see at a glance that user.roles contains two values.

Once formatted, the structure is readable in seconds: the top-level keys, the shape of nested objects, and where arrays begin and end. That's usually enough to spot a missing field, an unexpected null, or a response wrapped one level deeper than your code expects.

The errors you'll actually meet

• Trailing commas — JSON forbids a comma after the last item in an object or array: {"a":1,} is invalid, even though many JavaScript tools tolerate it.
• Single quotes — JSON requires double quotes for keys and strings. {'name': 'Ada'} is valid JavaScript but invalid JSON.
• Unquoted keys — {name: "Ada"} works in JS, not in JSON.
• Trailing garbage — a stray comma, bracket, or second document after the closing brace makes the whole payload invalid.
• NaN or undefined values — these aren't representable in JSON and usually indicate a serialization bug on the server.

The debugging workflow

1. Copy the raw response body from the network tab, curl output, or logs.
2. Paste it into a JSON formatter — if it prints, your syntax is valid and you can read the structure.
3. If it refuses to format, read the error location and fix the reported character (usually a missing quote, extra comma, or truncation).
4. Compare two versions of a response with a diff tool when the payload changed between requests.

When the JSON is JSON twice

A surprisingly common trap: some APIs return a string field whose value is itself a JSON-encoded string — {"data": "{\"id\":42,\"name\":\"Ada\"}"} — because a serialization layer double-encoded it somewhere upstream. A formatter handles the outer object correctly, but the data field still shows as one long escaped string rather than a readable object. You have to copy that value out and format it a second time before the nested structure becomes visible. This happens most often when a gateway, proxy, or logging pipeline wraps someone else's already-serialized JSON as a string field instead of embedding it as a real nested object.

When the response isn't JSON at all

A formatter given non-JSON input — an HTML error page from a proxy, an empty body from a 204, a stack trace instead of the expected payload — fails to parse, and the error location it reports is honest but easy to misread. It points at the first character that doesn't fit, which for an HTML response is usually the opening < of <!DOCTYPE. That's diagnostic in itself: if a formatter's error points at position 0 complaining about an unexpected character, the response probably isn't JSON at all, and the real bug is upstream of your code — a proxy returning its own error page, a wrong Content-Type header, or a server crashing before it produces the response your client expects.

Comparing two responses instead of reading one

Formatting solves the one-response problem. A different, equally common situation is having two versions of a response — before and after a deploy, from staging versus production, or from two runs of the same request — and needing to know what actually changed. Reading two large formatted documents side by side and spotting the difference by eye is slow and error-prone once a payload passes a few dozen keys; a diff tool that walks both structures and reports exactly which keys, values, or array elements differ is the faster and more reliable path, and it catches changes a quick scan would miss, like a field that silently changed type from a number to a numeric string.