HAR File Analyzer
Open a HAR file and see the network waterfall, timing breakdown and findings — plus a one-click redacted copy safe to send, since HAR files leak tokens.
HAR file
exported from the Network panelIn Chrome or Edge: DevTools → Network → right-click any request → Save all as HAR with content. In Firefox: Network → the gear icon → Save All As HAR.
The file is read with the File API and parsed in your browser. A HAR file contains every request header you sent, so it is exactly the kind of file that should never be uploaded to analyse it.
About the HAR File Analyzer
Open a HAR file and get the network waterfall back: every request with its status, size and timing, grouped by resource type and by host, with the slow and oversized ones called out. The file is read with the File API and parsed in your browser — nothing is uploaded.
That is not a marketing line on this particular tool, it is the point of it. A HAR file is a complete record of a browsing session, and it includes every request header you sent. Every Authorization: Bearer token, every session cookie, every API key is sitting in it in plain text — and “export a HAR and send it to us” is the standard thing a support team asks for. People routinely email their own credentials without realising, and uploading the file to a web analyser to read it is the same mistake with an extra copy.
So this HAR file analyzer does two things. It shows you what is in the capture, and it produces a redacted copy you can actually send: credential headers replaced, cookies emptied, request and response bodies removed, and sensitive-looking query parameters masked in both the queryString array and the URL itself. The result is still a valid HAR that opens in any viewer.
The analysis flags what usually matters: 4xx and 5xx responses, requests that never got one, plain http, requests over a second, responses over 500 KB, text that arrived uncompressed, redirect chains and duplicate GETs.
- Waterfall with each request positioned by its real start offset
- Redaction pass that produces a shareable .har, listing exactly what it removed
- Grouping by resource type and by host, sorted by bytes
- Filter by type and sort by slowest or largest
- Findings for failures, insecure requests, slow and large responses, missing compression and duplicate GETs
- Page load (onLoad) timing shown in the summary when the capture includes a page
- The seven HAR timing phases explained, including which one is actually server time
How to use it
- Export the capture: in Chrome or Edge, DevTools → Network → right-click → Save all as HAR with content. In Firefox, Network → gear icon → Save All As HAR.
- Open the file with the button above. Large captures are fine — nothing is transmitted, so there is no upload to wait for.
- Read the Findings panel, then sort by Slowest first to see where the time actually went.
- Before sending the file to anyone, press Download redacted .har. Check the list of what was removed.
- Use the type filter to isolate xhr requests when you are debugging an API rather than a page load.
Real-world use cases
Frontend & performance engineers
Work out where a slow page load actually went — the waterfall and the Waiting-phase breakdown separate a slow backend from browser connection queuing or a render-blocking asset.
Backend & API developers
Find the failing or slow endpoint from a captured session without asking the reporter to describe it — sort by status or by Slowest first and see exactly which request it was.
Support & QA engineers
Read a customer-submitted HAR to see what actually happened, then hand back a redacted copy that is safe to attach to the ticket instead of the original file with their session token still in it.
Security & AppSec engineers
Audit a captured session for requests still on plain http, credential headers sent where they should not be, or a token showing up unexpectedly in a query string.
DevOps & SRE
Spot duplicate GETs, uncompressed text responses and redirect chains adding avoidable latency to a session, using the By host and By type breakdowns to see where the bytes went.
Examples
What redaction removes
"headers": [
{"name": "Authorization", "value": "Bearer eyJhbGciOi…"}
]"headers": [
{"name": "Authorization", "value": "[redacted]"}
]The header is kept and its value replaced, so a reader can still see that authentication was sent. Response bodies are removed outright rather than replaced — a truncated body is worse than none.
Sensitive query parameters, in both places
https://api.example.com/v1?api_key=live_abc&page=2
https://api.example.com/v1?api_key=[redacted]&page=2
The parameters appear twice in a HAR — in request.url and in request.queryString. Redacting only one of them leaves the key in the file.
An uncompressed text response
app.js — content.size 50,000, response.bodySize 50,000
Warning: 1 text response arrived uncompressed.
When the transferred size matches the decompressed size, nothing was compressed. Only flagged above 1 KB, where compression would actually help.
Reading the timing phases
blocked 2ms, dns 0ms, connect 0ms, send 1ms, wait 780ms, receive 12ms
The server took 780 ms. The network took 15 ms.
Waiting is time to first byte — the server thinking. A slow request with a large wait is a backend problem, not a network one.
Common errors
| Message | Cause | Fix |
|---|---|---|
| This is valid JSON, but not a HAR file. | The file parsed but has no top-level log object — often a JSON response saved by mistake rather than the capture. | Re-export with Save all as HAR from the Network panel, not Copy response. |
| Unexpected end of JSON input | The file was truncated, usually by pasting a large capture into a box with a length limit. | Use Open a .har file rather than pasting. Nothing is uploaded either way. |
| Sizes show as — or as 0 | The capture was exported without content, or the browser recorded bodySize as -1 because the response came from cache. | Re-export with Save all as HAR with content. Cached entries genuinely have no transfer size, and are marked cached above. |
| status 0 with no response | The request never completed: blocked by CORS, cancelled by a navigation, blocked by an extension, or a DNS failure. | Check the browser console from the same session — a HAR records that the request failed but not why the browser refused it. |
| The waterfall looks wrong or everything starts at zero | Some capture tools write the same startedDateTime for every entry, so there are no real offsets to plot. | The per-request time column is still accurate. Sort by Slowest first, which does not depend on offsets. |
| I already emailed a HAR with my token in it | The export includes every request header verbatim, including Authorization and Cookie. | Rotate the credential. It should be treated as leaked the moment the file left your machine — redaction after the fact does not help. |
Frequently asked questions
›Is my HAR file uploaded?
No. The file is read with the File API and parsed in this browser tab. Nothing is transmitted, which is the entire reason this tool exists — the file you are analysing typically contains live session cookies and bearer tokens, and uploading it to read it defeats the purpose. You can verify the claim by disconnecting your network and opening a file.
›What exactly is in a HAR file?
Every request and response of the recorded session: full URLs including query strings, all request and response headers, cookies, timings, sizes, and — if it was exported with content — the response bodies too. That means auth tokens, session cookies, API keys in query strings, and whatever personal data those responses contained. It is one of the most sensitive files a browser will produce for you on request.
›What does the redaction actually remove?
Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-API-Key, X-Auth-Token, X-CSRF-Token and X-Amz-Security-Token header values; both cookie arrays; request bodies; response bodies; and any query parameter whose name looks sensitive — token, key, secret, password, auth, session, signature or code — in both the queryString array and the URL. Everything else is untouched, so the file still opens in any HAR viewer and the timings are intact.
›Is a redacted HAR safe to send?
Much safer, not provably safe. It removes the credentials in the places credentials are normally found, but it cannot know that a custom header called X-Tenant-Context holds a signed token, and it does not touch URLs' path segments, which sometimes contain identifiers. Read the list of what was removed and skim the request table before sending. If a credential was ever in the original file, rotate it regardless.
›Which timing phase should I look at?
Waiting — time to first byte. It is the server thinking, and in most slow requests it is nearly all of the elapsed time. Blocked means the request was queued behind the browser's per-host connection limit, which points at too many parallel requests rather than a slow server. DNS and connect only appear on the first request to each host.
›How is uncompressed detected?
By comparing content.size, which is the decompressed body, against response.bodySize, which is what came over the wire. If they are within 5% of each other on a text resource over 1 KB, nothing was compressed. Images and video are excluded because they are already compressed, and gzipping them again gains nothing.
›Can it handle a large capture?
A few thousand requests is fine. Everything is parsed and rendered synchronously, so a very large capture — tens of megabytes from a long session — will make the page sluggish. Filtering by resource type helps, and recording a shorter session helps more: a HAR of the one failing request is more useful to whoever reads it than a HAR of twenty minutes of browsing.
›What does the Load figure in the summary mean?
The time from navigation start to the window's load event, taken from the capture's page timings — the same number a browser's own performance panel would show for onLoad. It only appears when the HAR was exported with a page attached, which Save all as HAR provides; a HAR built by hand or filtered down to a handful of entries usually has no page object and so no Load figure.
Last updated