Free · Fast · Privacy-first

Format JSON for API Response Debugging and Docs

API responses are minified for speed but unreadable for humans.

⚡

Instant pretty print for any API response

🔒

Reveals nested structure and field names

✨

Copy formatted output for documentation

⚡

No tools, plugins, or accounts needed

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this JSON Formatter to your website

Drop the JSON Formatter into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/json/json-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/json/json-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why API Responses Are Minified and Why That Makes Debugging Harder

HTTP APIs return minified JSON because whitespace increases payload size. A response with 50 key-value pairs at two nesting levels can be 30 to 40 percent larger with 2-space indentation than without any indentation. For a high-traffic API serving millions of requests per day, this payload size difference has a measurable cumulative impact on bandwidth costs and on response latency for clients on slow connections. Content-Encoding: gzip compresses repetitive whitespace very efficiently, which is why some APIs accept the bandwidth cost when gzip encoding is enabled. Many APIs default to uncompressed responses for simplicity and return minified JSON regardless of encoding support, making minification the primary size reduction strategy.

The result is that every developer working with a new API spends time decoding response structure from a dense single-line string. REST clients like Postman and Insomnia auto-format responses in their built-in UI panels, but when you capture a response from a browser DevTools Network tab, a curl command output, a server log file, or an error report from a colleague, you get the raw minified string. Pasting it into a formatter is the standard first step for initial exploration: see the full field list, identify nested objects, understand the structure of arrays, and confirm the data shape before writing deserialization code or assertion logic.

Formatted API responses are also the accepted standard for API documentation. REST documentation generators like Swagger UI and Redoc automatically display example responses with consistent indentation derived from the OpenAPI schema. When writing documentation manually or supplementing generated documentation with real examples, starting with an actual formatted response from the running API ensures the example matches what the API currently returns. This prevents documentation drift, where hand-written examples fall out of sync with the actual response structure as the API evolves over time.

API responses also surface JSON spec edge cases that internal data rarely hits. Some APIs return NaN or Infinity for failed numeric calculations, both of which are illegal in strict JSON and trigger parse errors in any RFC 8259-compliant client. Others use JSONP wrapping where the response body is callback({...}) rather than bare JSON; the parentheses and callback name must be stripped before formatting. Cross-Origin Resource Sharing prefixes such as )]}', the anti-hijacking prelude used by Google APIs and Angular HTTP, also need to be removed from the leading bytes. When pasting an API response into FixTools and getting an unexpected token error at position 0 or 1, suspect a wrapper or prelude rather than the JSON itself, and trim those characters before reformatting to see the real structure.

Pagination patterns add another layer of structure that formatting makes visible. Cursor-based APIs return a top-level data array alongside a next or after field that holds the cursor for the next request. Offset-based APIs return data plus a meta or pagination object with total, offset, and limit fields. Link-header APIs return only the data array and embed the next-page URL in the HTTP Link response header rather than the body. Each pattern requires different client code, and the correct approach is impossible to guess from a minified response. Formatting the response and the response headers side by side reveals which pattern this particular API uses, which is the single most useful piece of information before writing any pagination loop in the client.

ECMA-404 JSON standard RFC 8259 JSON specification

How to use this tool

💡

Paste the raw JSON from a curl response, browser Network tab, or API client to instantly see the full response structure with indentation.

How It Works

Step-by-step guide to format json for api response debugging and docs:

1
Capture the API response
Copy the JSON response body from your API client, browser DevTools Network tab Response sub-tab, curl terminal output, or log file. Select all content in the response area and copy it to your clipboard.
2
Paste into FixTools
Paste the raw JSON into the FixTools JSON Formatter input area. The editor accepts the full response body regardless of its length or complexity.
3
Click Format
The formatter validates the response JSON and pretty prints it with consistent indentation and full syntax highlighting showing keys, string values, numbers, booleans, and null in distinct colours.
4
Explore the structure
Scroll through the formatted output to identify top-level keys, nested objects, and arrays. Use the browser Ctrl+F to search for specific field names or values within the formatted response.
5
Copy for docs or code
Copy the formatted response to use as an example in API documentation, as a reference when writing deserialization code, or as evidence in a bug report that clearly shows the response structure.

Real-world examples

Common situations where this approach makes a real difference:

A developer integrating the Stripe API copies a webhook payload from their server log. The payload is a 600-character single-line string. Pasting into FixTools reveals the payload has a "data.object" key containing a nested charge object with 40 fields, including a "metadata" sub-object the developer had not noticed in the Stripe documentation. Seeing this extra context in the formatted view prevents a bug in the webhook handler that would have silently ignored the metadata fields.

API responses often contain undocumented or lightly documented fields that only become visible when the response is formatted.

A technical writer documenting an internal REST API asks a developer to send a sample response. The developer pastes the raw response into FixTools, formats it with 2-space indentation, and sends the formatted version to the writer. The writer pastes it directly into the API documentation as an example response, with all field names, types, and nesting levels correctly visible, saving 20 minutes of manual reformatting and reducing the risk of transcription errors.

Formatted API responses are documentation-ready without further editing and reflect the actual API output rather than a manually written approximation.

A QA engineer runs end-to-end tests and a test assertion fails with a message showing the raw API response as a single line. The engineer pastes the response into FixTools and sees that the "items" array in the response body has zero elements, while the test expected three. The formatted view makes the empty array obvious in a way the compressed single-line string did not, immediately pointing to a data setup issue in the test environment rather than a code bug.

Formatting API responses during test failure investigation reveals structural issues like empty arrays and missing keys that are invisible in minified output.

A frontend developer building a paginated data table consumes a list API where the first page loads correctly but the second page triggers a JavaScript error. Formatting both the first and second page responses in separate FixTools tabs and comparing them reveals that the second page response is missing the "pagination.nextCursor" field entirely. The frontend code expects this field and throws an error when it is absent. The bug is in the backend pagination logic, confirmed by the formatted comparison.

Formatting multiple API responses and comparing them side by side exposes inconsistencies between pages, versions, or parameter combinations that cause integration bugs.

Pro tips

Get better results with these expert suggestions:

Use curl -s URL | python3 -m json.tool for quick terminal formatting

In a terminal, piping a curl response body to python3 -m json.tool produces indented JSON output directly. Use curl -s URL | python3 -m json.tool to format any API response without leaving the terminal. For more powerful filtering, pipe to jq instead: curl -s URL | jq "." for full formatting or curl -s URL | jq ".data.items" to extract a specific path. Both options require only curl and the respective tool to be installed.

Copy response from Chrome Network tab

In Chrome DevTools, open the Network tab, click the API request you want to inspect, select the Response sub-tab, right-click in the response body area, and choose "Copy". This copies the raw response text to your clipboard. For a quicker method, right-click the request row in the Network tab and choose "Copy > Copy response" to get the response body without navigating to the sub-tab.

Format before writing deserialization code

Before writing a struct, interface, class, or schema to deserialize an API response, format a real example response from the live API and read through every field. This prevents typos in field names, incorrect type assumptions, and missed optional fields, which are the most common bugs in API integration code. The formatted view makes the complete field list visible without parsing the response in code first.

Include formatted examples in bug reports

When filing a bug related to an unexpected API response, include the formatted JSON in the ticket rather than the minified version. Reviewers can read the formatted response immediately and understand the structure without any preparation. This reduces back-and-forth requests for a readable version of the response and speeds up triage and investigation.

FAQ

Frequently asked questions

Minified JSON has all insignificant whitespace removed, which reduces payload size. For a typical API response with many fields and nested objects, minification reduces the payload by 20 to 40 percent compared to indented output. This reduces bandwidth costs and improves response times, particularly on mobile connections where every kilobyte matters. When HTTP gzip compression is used, the advantage of minification is smaller because gzip compresses repetitive whitespace efficiently, but many APIs still default to minified output regardless of compression settings.

Open DevTools with F12 (Windows/Linux) or Cmd+Option+I (macOS). Go to the Network tab and click the request you want to inspect. Click the Response sub-tab to see the raw response body. Right-click anywhere in the response area and choose Copy to copy the full text. Alternatively, select all text with Ctrl+A (Windows/Linux) or Cmd+A (macOS) and then copy. Paste the copied text directly into FixTools to format it.

Postman formats JSON responses automatically in its response panel. If you need to use the raw response in FixTools, select the "Raw" view in Postman's response body section, select all the text, copy it, and paste it into FixTools. Postman also offers the ability to copy the entire request as curl, which you can run in a terminal and pipe to FixTools or to python3 -m json.tool for formatting in place.

Format a real response from the running API and use it as the example in your documentation. Real formatted responses are more accurate than hand-written examples because they contain the actual field names, data types, and nesting structure that the API currently returns. Add field descriptions alongside the example. For formal API documentation, OpenAPI and Swagger tools generate example responses from schema annotations, but a real formatted response is the fastest way to produce accurate documentation for internal or exploratory purposes.

Format both responses in FixTools separately by pasting each one and clicking Format. Then copy both formatted outputs and paste them into the FixTools Diff Checker at fixtools.io/developer/diff-checker. The diff checker highlights added, removed, and changed fields between the two formatted documents. This is useful for checking what changed between two API versions, two different endpoints, or the same endpoint called with different parameters.

No. Formatting only adds whitespace characters. The underlying data structure represented by the JSON is identical whether the response is minified or formatted. Any RFC 8259-compliant JSON parser reads both forms and produces the same in-memory data structure. Formatting is purely for human consumption during development, debugging, and documentation. You do not need to parse the formatted version; format it for reading, then use the original minified version in code.

After formatting in FixTools, use Ctrl+F (Windows/Linux) or Cmd+F (macOS) to search for a specific field name or value. For extracting fields programmatically, use jq in a terminal: echo '{"data":{"name":"Alice"}}' | jq '.data.name' extracts a nested field by path. In JavaScript, use JSON.parse(responseText) and access nested fields using dot notation or bracket notation. In Python, use json.loads(response_text) and access fields with dictionary key access.

Not all API responses are JSON. Check the Content-Type response header in DevTools to determine the format. application/json indicates JSON. text/xml or application/xml indicates XML, which requires an XML formatter. text/html indicates an HTML error page, which often appears when an API request hits an error handler that returns HTML instead of JSON. If the response is JSON but FixTools shows a syntax error, the response may be wrapped in a callback function name (JSONP format) or prefixed with a security header that needs to be stripped first.

Server-Sent Events and HTTP streaming endpoints often deliver newline-delimited JSON (NDJSON or JSON Lines) where each line is a separate JSON object rather than one large array. Pasting the whole stream into FixTools fails because the body is not a single document. Instead, format one line at a time, or wrap the stream in brackets and add commas between records using a regex such as sed 's/}$/},/' followed by manual top and tail bracket insertion. For repeated work, jq has a --slurp flag that converts NDJSON into a single array: cat events.ndjson | jq -s . produces an array of objects ready for FixTools or any standard JSON tool.

FixTools formats client-side and never transmits data, so the response stays in your browser. The real concern is the surrounding workflow. Production responses often contain personally identifiable information such as email addresses, names, and customer identifiers that should not appear in screenshots attached to bug tickets or in chat messages. Before pasting into a public ticket, redact PII manually or with a sed pipeline. If your organisation has a data classification policy, treat formatting tools the same as any other text editor: acceptable for internal debugging, requires redaction for external sharing, and forbidden for regulated categories like PHI or PCI without a documented exception.