HAR File Viewer
View and analyze HAR file contents.
Overview
A HAR file is a JSON record of everything the browser loaded, exported from DevTools. It is precise and almost unreadable by eye. This viewer turns it back into the waterfall you were looking at in DevTools, so you can read a capture someone sent you without opening their browser.
Each bar is split into the phases the browser actually recorded: time blocked in the queue, DNS, connecting, the TLS handshake, waiting for the first byte, and downloading. A long bar that is almost entirely TTFB is a server problem; a long bar that is almost entirely download is a payload problem.
How to use
- In DevTools, open Network, right-click the request list and choose Save all as HAR.
- Drop the file here, or click to browse. Nothing leaves the page.
- Filter by resource type, and click a row to see its URL and full phase breakdown.
- Read TRANSFER BY TYPE to find what actually dominates the page weight.
Reading the phases
The six segments are recorded by the browser, not derived, and each one points at a different owner of the problem.
| Phase | What it measures | Who owns a long one |
|---|---|---|
blocked | Queued in the browser, waiting for a connection slot | The page — too many parallel requests, or HTTP/1.1 |
dns | Name resolution | DNS provider, or a cold cache on first visit |
connect | TCP handshake | Network distance to the origin |
tls | TLS handshake | Certificate chain length, or no session resumption |
ttfb | Waiting after the request was sent | The server. Almost always application or database time |
download | Receiving the body | Payload size, or bandwidth |
A value of -1 means the browser did not record that phase, which is normal:
a request reusing an existing connection has no dns, connect or tls at
all. The tool omits those segments rather than drawing them as zero.
Two patterns are worth learning to spot. A row where blocked dominates and
many rows share the same host is connection contention — the fix is fewer
requests or HTTP/2, not a faster server. A row where ttfb dominates on the
document request means every other bar in the capture starts late; nothing
downstream can be faster than that number.
Reading the waterfall shape
The horizontal position of each bar matters as much as its width. Requests are placed on a shared timeline, so a staircase means serialisation: each request could not start until an earlier one finished. The usual causes are a stylesheet that blocks rendering, a synchronous script that blocks the parser, or a JSON response that contains the URLs for the next round of requests.
The DCL and LOAD marks come from the capture’s own page timings. Requests
to the right of LOAD did not affect the load event — lazy images, analytics
beacons, prefetches. Requests to the left of DCL are on the critical path
whether you meant them to be or not.
What is masked on screen
The viewer shows header and parameter values so you can debug with them, with
one exception: values whose names look like credentials — Cookie,
Authorization, token, api_key, signature, code, state — are
displayed masked. That is a shoulder-surfing guard, not a security boundary.
The file on your disk is unchanged and still contains every secret.
If you need a version you can attach to an issue or send to a vendor, use the HAR sanitizer. It rewrites the JSON — clearing cookie arrays, request and response bodies, redirect targets and WebSocket frames — and hands back a file that is safe to share.
Examples
- Slow first paint: look for a wide TTFB segment on the document request — the server, not the network, is the cost.
- Oversized page: the transfer bar usually makes it obvious that images or a single JS bundle account for most of the bytes.
- Broken deploy: filter to
jsand look for 404s left over from a stale reference. - A third party you forgot about: sort by host in the transfer breakdown. Tag managers tend to pull in more than the person who added them expected.
- “Fast for me, slow for the user”: compare their capture against yours.
Differences in
dnsandconnectare geography; differences inttfbon the same endpoint are usually cache state.
Notes
Sizes come from the capture’s transfer size where present, falling back to body plus headers, then to the decoded content size — in that order, because different exporters populate different fields.
Resource type is inferred from the URL extension first and the MIME type
second, because an error page returns text/html even for a request that was
meant to be a script.
Captures from different browsers are not directly comparable. Firefox and
Safari populate different optional fields, and Chrome adds non-standard
_initiator and _webSocketMessages entries. This viewer reads the standard
fields and ignores the rest, so a Firefox capture renders with less detail
rather than failing.
If you do not have a capture handy, load sample capture opens a small synthetic HAR so you can see how the panel reads. It is demo data, labelled as such in the header — not a real measurement.