HAR File Viewer

about this tool

Open the file devtools gave you

A HAR is what your browser writes when you choose "Save all as HAR" in the network panel: a JSON archive of every request the page made. It is verbose, deeply nested, and almost unreadable on its own.

Drop it here and it becomes one row per request — status, method, path, host, size, time — with a waterfall underneath showing where each request sat on a single shared timeline.

The bar is the point

A list sorted by duration tells you which request was slow. The waterfall tells you something more useful: whether it was slow, or merely late.

A request that finished last may have started last, waiting on something before it. That distinction is where page-load problems actually live, and it is invisible in a table of numbers.

Open any row for the phases the browser recorded — blocked, dns, connect, ssl, send, wait, receive — with the longest one marked. A large wait is the server thinking. A large blocked usually means too many requests queued against one host.

A HAR is a file full of passwords

This is the part most HAR tools do not say.

The archive records requests verbatim, which includes every Authorization header and every session cookie. Anyone you send it to can replay your session. People paste them into support tickets and chat threads constantly.

So: nothing is uploaded here — it is read in your browser and stays there — and any request carrying credentials is flagged in the list rather than left for you to notice.

Download redacted copy blanks the Authorization, Cookie, Set-Cookie and similar headers, empties the cookie lists, blanks query parameters that look like tokens — in the URL as well as in the parallel queryString list — and blanks credential-named fields inside request and response bodies, so the password a login posts and the token it gets back both go. It works on the original text rather than on what this tool parsed, so timings, cache metadata and the rest of every body survive untouched and the result still opens in any other HAR viewer.

It matches on names, so it finds a token in JSON or in a form and cannot find one sitting loose in HTML or in some binary payload. Skim what comes out before you send it.

Send that one.

Filtering

The type buttons work like the devtools filter bar, and stack — pick script and stylesheet to see both. Problems only keeps anything that did not come back 2xx, which is usually the fastest way to find what is actually broken.

The list draws the first 300 matching rows, because a few minutes of browsing can record several thousand requests and drawing them all locks the tab. Narrow the filter to reach the rest.

Sizes

A size of zero usually means the response came from cache: the file records -1 for the body size when the browser did not send one, and the decoded content size is used instead. Rows served from cache are marked rather than shown as nothing.

To turn one of these requests back into code, use the cURL converter.

questions

Is my HAR uploaded?

No, and on this tool that matters more than on any other. A HAR records every request a page made, including the Authorization headers and session cookies — so it is a file full of live credentials. It is read in your browser and nothing is sent anywhere.

Someone asked me to send them a HAR. Is that safe?

Not as it comes out of the browser. Anyone holding it can replay your session. Use the redacted copy: it blanks Authorization, Cookie, Set-Cookie and similar headers, empties the cookie lists, blanks token-shaped query parameters in the URL itself, and blanks credential-named fields inside JSON and form bodies — while leaving everything else untouched, so it still opens in any HAR viewer. It matches on names, so skim the result before you send it.

What is the bar under each row?

Where that request sat in the capture: how far in it started and how long it ran, on one shared timeline. It is the quickest way to see whether something was slow or merely late — a request that finished last may have started last.

What do the timing phases mean?

They are the phases the browser recorded: blocked waiting for a connection, dns, connect, ssl, send, wait for the first byte, and receive. Open a row to see them, with the longest one highlighted. A large "wait" is the server thinking; a large "blocked" usually means too many requests to one host at once.

Why does a request show no size?

The file records -1 when the browser did not say, which usually means it came from cache. Where the body size is missing the decoded content size is used instead, and a row served from cache is marked as such rather than shown as zero bytes.

How big a file can it open?

Large ones are fine — the parsing is a single pass and only the fields it needs are kept. The list draws the first 300 matching rows so a capture of several thousand requests does not lock the tab; narrow the filter to reach the rest.