API Response Formatter
Make sense of an API response in one step. Paste the body, or the complete output of curl -i or curl -v, and the tool separates headers from body, formats JSON or XML, explains the status code and pulls out what matters: the error message, rate limits and the request ID.
- Runs in your browser
- No sign-up
- Free to use
| Response header | Value |
|---|
How to use API Response Formatter
- Paste the response, including the status line and headers if you have them.
- Select Format response.
- Read the summary: status meaning, error message, rate limit and notes.
- Copy or download the formatted body.
API Response Formatter features
Headers and body separated
Understands the output of curl -i and curl -v, including redirect chains and 100 Continue.
JSON, XML, HTML, form data
Detects the body type from the Content-Type header or the content and formats it accordingly.
Status explained
The status code is named and explained, with advice for the common error codes.
Error and rate-limit details
Finds the error message in the body and reads Retry-After and X-RateLimit headers.
Nested JSON expanded
JSON that was serialised into a string field is unpacked into readable structure.
Wrappers removed
Strips JSONP callbacks, anti-hijacking prefixes and chunked transfer framing.
When to use API Response Formatter
- Debugging a failing API call from a terminal or a log file.
- Reading a minified webhook payload.
- Sharing a readable response in a bug report.
- Checking rate-limit headers while building an integration.
API Response Formatter FAQ
How is this different from the JSON Formatter?
The JSON Formatter expects JSON and nothing else. This tool accepts what an HTTP client actually prints: a status line, headers and a body that may be JSON, XML, HTML or form data. It formats the body and also interprets the response as a whole.
How do I get a response with headers?
With curl, add -i to include response headers, or -v for the full exchange. In browser developer tools, open the Network tab, select the request and copy the response headers and body.
What does “Expand JSON inside strings” do?
Some APIs put a JSON document into a string field, which appears as one long line full of backslashes. With this option the string is parsed and shown as nested data. Turn it off to see the response exactly as sent.
Why is my JSON reported as invalid?
Often the copy is incomplete: a response cut off by a terminal, a log line limit or a timeout. The message gives the position where parsing stopped. An HTML error page returned in place of JSON is another common cause, and is detected separately.
Does it handle JSON Lines?
Yes. When the body has one JSON document per line, as streaming and logging APIs produce, the lines are parsed individually and shown as an array.
Is the response uploaded?
No. Responses often contain tokens and personal data, so everything is processed in your browser. Still, remove secrets such as API keys before pasting a response into a public bug report.
Reading an HTTP response
Every HTTP response has three parts. The status line gives the protocol version and a three-digit code. The headers are name and value pairs carrying metadata. After a blank line comes the body. When an API call fails, the answer to “why” is nearly always in one of the three, and reading them in order is the fastest way to it.
The first digit of the status code sets the direction. A 2xx code means the server accepted the request. A 3xx code redirects. A 4xx code says the request itself is the problem: wrong URL, missing credentials, invalid data, too many requests. A 5xx code says the server failed. This distinction decides what to do next. A 4xx will fail again if sent unchanged, so the request has to be fixed. A 5xx or a 429 may succeed later, so retrying after a pause is reasonable.
Headers answer the follow-up questions. Content-Type says how to interpret the body. Retry-After and the rate-limit headers say how long to wait and how much quota is left. Location says where a redirect leads. A request or correlation ID identifies the call in the provider's logs, which makes it the most useful thing to include in a support request. Cache-Control and ETag explain why a response may be stale.
The body of an error response usually contains a machine-readable code and a human-readable message, increasingly in the standard “problem details” format with type, title and detail fields. Well-designed APIs also name the offending field for validation errors. When the body is HTML although JSON was expected, the response did not come from the API itself but from something in front of it: a proxy, a firewall, a login page or a load balancer reporting that the service is down.