Skip to content

HAR Viewer & Sanitiser

Opens a HAR capture as a waterfall and strips cookies, auth headers and tokens before you share it.

Opens a HAR capture from a browser’s network panel and draws the waterfall: every request, where its time went, and what each response actually carried. It also produces a sanitised copy — a raw HAR is a full session credential, and this is the page that says so.

🔒 Runs entirely in your browserharnetworkdebugprivacy

Drop a .har capture

DevTools → Network → "Save all as HAR". Opened in this tab; nothing is uploaded.

A raw HAR carries every cookie, auth header and URL token of the session that recorded it — treat it like a password until sanitised. The sanitiser redacts by name (cookies always; headers and parameters on a sensitive-name list) and can drop bodies; it does not claim to find secrets hidden inside kept bodies.

How to use it

  1. Save the HAR

    DevTools, Network panel, "Save all as HAR". Drop the file here or paste the JSON — it is opened in this tab and nothing is uploaded.

  2. Read the waterfall

    Each bar is split into its phases — blocked, DNS, connect, SSL, send, wait, receive — with the same colours in the legend. Long grey means queueing; long pink means the server was thinking.

  3. Click a row for the detail

    Status, MIME type, body and transfer sizes, the server IP, the numeric timing table and both header lists.

  4. Sanitise before you share it

    The last panel strips cookies, redacts sensitive-looking headers and URL parameters, and optionally drops all bodies. It reports exactly how many of each it changed.

Common questions

Is it safe to send someone a HAR?

Not unsanitised. A raw HAR contains every cookie, `Authorization` header and URL token of the session that recorded it — sending one is closer to sending a password than to sending a log. Support requests have leaked live sessions this way.

Does the sanitiser find every secret?

No, and it does not claim to. It redacts by name — cookies always, headers and query parameters on a sensitive-name list — so a token in a response body under an unremarkable key survives. That is why dropping bodies is the default.

Why is one bar almost entirely grey?

Grey is `blocked` — the request existed but was not being worked on, usually waiting for a connection under the browser’s per-host limit. It is the phase that says the fix is fewer requests or a different protocol, not a faster server.

Are the bodies of responses shown?

Not in the viewer — it shows sizes, headers and timings. Whether the bodies are in the file at all depends on the "content" option your browser used when saving, and if they are there they are the riskiest part of the capture.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.