sitekits.dev
press ⌘K to switch tools
NETWORK · HAR

HAR File Viewer

View and analyze HAR file contents.

local
❯ har
drop a .har capture here — or click to browseDevTools → Network → right-click → “Save all as HAR”parsed in this tab · captures often hold cookies and tokens — they stay here
§01 ABOUT THIS TOOL

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

  1. In DevTools, open Network, right-click the request list and choose Save all as HAR.
  2. Drop the file here, or click to browse. Nothing leaves the page.
  3. Filter by resource type, and click a row to see its URL and full phase breakdown.
  4. 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.

PhaseWhat it measuresWho owns a long one
blockedQueued in the browser, waiting for a connection slotThe page — too many parallel requests, or HTTP/1.1
dnsName resolutionDNS provider, or a cold cache on first visit
connectTCP handshakeNetwork distance to the origin
tlsTLS handshakeCertificate chain length, or no session resumption
ttfbWaiting after the request was sentThe server. Almost always application or database time
downloadReceiving the bodyPayload 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 js and 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 dns and connect are geography; differences in ttfb on 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.

FAQ
Is my capture uploaded anywhere?
No. The file is read with the browser's FileReader and parsed in the page. Nothing is sent to a server. That matters more than usual here — HAR captures routinely contain cookies, Authorization headers and session tokens.
What do the colours in each bar mean?
They are the HAR timings for that request, in order — blocked, dns, connect, tls, ttfb (wait) and download (receive). The widths are the recorded values as a proportion of that request's total time, not estimates.
Why does a request show no size, or "cache"?
HAR records the transfer size only when the browser knows it. A request served from the HTTP cache transfers no bytes on the wire, so the tool shows "cache" rather than inventing a number.
Where do the DCL and LOAD lines come from?
From the capture's own page timings (onContentLoad and onLoad). If the HAR has no pages section — some exporters omit it — the marks are simply not drawn.
Can I share the capture after viewing it here?
Not as-is. This viewer masks secrets on screen but does not change the file. Run it through the [HAR sanitizer](/har-sanitizer/) first, which rewrites the JSON and gives you a version safe to attach.