Debug API requests with a HAR capture
Export a HAR from your browser dev tools, load it, and inspect each request and response — method, status, headers, body, and timing — without re-running the call or uploading the capture.
Open the tool, then paste the sample input below. Everything runs locally in your browser.
The problem
A failing API call is hard to debug from logs alone. A HAR file captures exactly what the browser sent and received, but it is a large JSON blob. Loading it into a viewer lets you read the request and response for one call side by side, so you can see the header or status that explains the failure.
Sample input
{
"request": { "method": "POST", "url": "https://api.example.com/orders",
"headers": [ { "name": "Authorization", "value": "Bearer ..." } ] },
"response": { "status": 401, "headers": [ { "name": "WWW-Authenticate", "value": "Bearer error=invalid_token" } ] }
}
Expected output
POST /orders -> 401 Unauthorized
Request header Authorization: Bearer ...
Response header WWW-Authenticate: Bearer error="invalid_token"
The 401 plus the invalid_token challenge points straight at an expired or malformed bearer token — visible without re-running the request.
How to do it
- Export a HAR from your browser dev tools.
- Load the HAR file into the studio.
- Select the request you want to debug.
- Compare the request and response headers, body, and status.
- Identify the header or status that explains the failure.
Common mistakes
- Sharing a raw HAR that still contains cookies and tokens.
- Looking at the wrong entry when many requests share a URL.
- Ignoring the status code and reading only the body.
- Missing a redirect chain that changes the final response.
- Assuming the request failed when it was a CORS preflight.
Related tools
Related guides
FAQ
What is a HAR file?
A HAR file is a JSON capture of the HTTP requests and responses a browser made, including headers, bodies, status codes, and timing. You can export one from browser dev tools.
How do I debug an API call from a HAR?
Load the HAR, select the request, and compare its request and response headers, body, and status side by side. The mismatch or error header usually explains the failure.
Is the HAR uploaded when I load it?
No. The HAR is read locally in your browser. Nothing is sent to a server.
Why do I see a request I did not make?
Browsers issue extra requests such as CORS preflight OPTIONS calls and redirects. Look for the actual method and URL you expect.
Should I redact a HAR before sharing?
Yes. HAR files contain cookies, Authorization headers, and tokens. Sanitize the HAR before sharing it with anyone.
HAR inspection runs locally in your browser. Your capture is never uploaded.
Debug requests, sanitize captures, parse headers and generate snippets — plus every other utility.
Practical example and expected result
Export a HAR from your browser dev tools, load it, and inspect each request and response - method, status, headers, body, and timing - without re-running the call or uploading the capture. In practice, this is most useful when you need a quick, repeatable check on a HAR capture before adding it to a ticket, pull request, test fixture, or support note.
A realistic input for this workflow is { "request": { "method": "POST", "url": "https://api.example.com/orders", "headers": [ { "name": "Authorization", "value": "Bearer ..." } ] .... The expected result should resemble POST /orders -> 401 Unauthorized Request header Authorization: Bearer ... Response header WWW-Authenticate: Bearer error="invalid_token", with the same important values preserved.
Troubleshooting checklist
- Confirm you copied the complete HAR capture and not only a partial line or truncated preview.
- Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
- Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
- Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.
Next useful steps
- Open this example in API Debugging Studio → for a related validation or follow-up step.
- Sanitize the HAR first for a related validation or follow-up step.
- Parse HTTP headers for a related validation or follow-up step.
- Use Magic Box when you are not sure which tool should handle the next artifact.