Formatting a Messy API Response

How to Format a Messy API Response (JSON)

A copied API response usually arrives as one unbroken line. Servers strip whitespace before sending JSON over the wire, since the grammar treats spaces and newlines between tokens as insignificant, and every byte removed is a byte the network never has to carry.¹ That habit is good for bandwidth and bad for your eyes the moment you need to actually read what came back.

Why the response you copied looks like one long line

Open your browser's network panel after any API call and the response body usually renders as a single dense string. Frameworks serialize this way by default: JSON.stringify with no third argument produces the most compact valid output, and most server-side JSON encoders follow the same convention because it saves real bandwidth at scale.² A payload with forty nested fields becomes unreadable at that density, even though every character in it is perfectly valid JSON.

Pasting that line into this tool's input runs it through the browser's native JSON.parse, then re-serializes the result with JSON.stringify using whichever indent you picked. Consequently, the output is never a cosmetic reflow of your original text; it is a faithful rebuild of the same parsed data, just spaced out so nesting becomes visible at a glance.

Reading structure back into a flat string

Once indentation exists, each nesting level lines up under its parent key, so a value buried five layers deep shows its whole path just by looking at the left margin. That structural view is exactly what a single-line response destroys, and it is the first thing worth restoring before you try to debug anything inside the payload. Restoring that path is the whole reason to reach for a formatter instead of squinting at raw, unindented text.

Choosing an indent width for how you plan to use the output

Three indent options exist because different destinations call for different widths. A 2-space indent keeps deeply nested API responses compact enough to fit on screen without excessive horizontal scrolling, which is why it is the default most JSON tooling ships with, including Prettier, one of the most widely used code formatters.³ Four spaces reads more comfortably in a printed document or a walkthrough where every level needs to stand out clearly, at the cost of pushing deeply nested values further to the right.

Matching indent to a shared context

Tabs render at whatever width your own editor or terminal is configured for, so pasting tab-indented output into a codebase that already uses tabs keeps the formatting consistent with everything around it. If you are debugging on your own machine, the choice barely matters. If you are pasting the formatted result into a bug report, a Slack thread, or a wiki page, matching the indent your teammates already use in that context saves them from re-formatting it themselves.

Every indent option produces byte-identical *data*; only the surrounding whitespace differs. Switching between them costs one click and never risks altering a key or a value, so there is no reason to settle for the first option before checking whether a different width reads better for your specific screen. Try 4-space or Tab whenever 2-space output still feels cramped on a wide monitor.

When a response is too large for the text view alone

Some API responses, particularly paginated list endpoints or GraphQL results with several nested resolvers, run to thousands of lines once indented, since a GraphQL server's response always mirrors the shape of the client's original nested query.⁴ At that size, scrolling through formatted text to find one value stops being practical, which is exactly the gap the tree view fills: it renders your parsed data as collapsible nodes, and every object or array shows its key or item count before you ever expand it.

Working through deeply nested payloads

Large arrays and objects render their first 500 children immediately and load 100 more per click, so a response with thousands of entries never freezes the tab while it builds. If your response nests a list inside a list inside an object, as most paginated APIs do, expanding only the branch you actually care about is far faster than scanning a wall of indented text for the right closing brace.

Because parsing and tree construction both run in your browser, and inputs over roughly 500 KB move into a background Web Worker automatically, nothing about pasting a large production response sends it anywhere.⁵ That matters in particular for API responses, which routinely carry session tokens, internal IDs, or customer data you would not want to hand to a server-backed formatter.

When to use this

Use this guide any time a raw API response arrives as one dense line and you need to read its structure, pick an indent, or browse it as a tree before you debug or document it.

Examples

{"event":"order.created","data":{"id":"ord_9f3a","total":48.5,"items":[{"sku":"A1","qty":2},{"sku":"B7","qty":1}]}}

The same payload with 2-space indent: every key sits on its own line, the two items inside "items" line up under their shared parent, and the nesting depth of "id" versus "sku" is visible without counting braces.

A paginated endpoint returns 2,000 order records in one array, and the formatted text view runs to over 40,000 lines.

Switching to Tree view collapses the array to a single "items: Array(2000)" node. Expanding it renders the first 500 records with a button to load 100 more, so you can inspect the shape of one record without scrolling past the other 1,999.