HAR file viewer: see what a network log gives away, and remove it before you send it
A support desk asked you for a HAR file. Drop it here first. You get every request with its status, size and timings, the failures and the slow ones, and a list of the session cookies, Authorization headers, API keys, tokens, JWTs and passwords recorded in it. Save cleaned HAR writes a copy with each of those replaced by [removed by viewhack].
The file is read on your device. It is never uploaded.
What it shows
- A summary. Which browser or program saved the log, how many pages and requests it holds, the bytes transferred, the time from the first request to the last byte, every failed request (4xx, 5xx, and status 0 for requests that got no response, such as ones blocked by an ad blocker or cancelled), the five slowest requests, and every domain with its request count.
- A request table you can sort by any column and filter by text, status class (2xx, 3xx, 4xx, 5xx, no response) and domain, with a waterfall bar on each row drawn from the HAR timings: blocked, DNS, connect, TLS, send, wait (time to first byte) and receive. Save it as CSV: one row per request, with every timing phase in milliseconds.
- The detail of any request: its timing breakdown, request and response headers, query string, cookies, the POST body and the response body as text. A body saved as base64 (images, fonts and other binary files) is named with its size and not shown.
- A secrets panel listing every finding by kind and place: Cookie and Set-Cookie headers; Authorization and Proxy-Authorization headers (a Basic one is decoded to its user:password, to show that base64 hides nothing); headers named like X-API-Key, X-Auth-Token or X-CSRF-Token; values named token, access_token, id_token, refresh_token, code, key, sig, signature, session or secret in URLs, #fragments, form posts and JSON bodies; password fields; and JSON Web Tokens anywhere in the file, with their header and claims decoded (subject, issuer, issue and expiry time).
- Save cleaned HAR, with a checkbox per kind, all ticked at first. The copy is still a valid HAR file that opens in browser devtools and HAR analysers, with the same requests in the same order. Names stay and only values go, so
Cookie: sid=8f3a…; theme=darkbecomesCookie: sid=[removed by viewhack]; theme=[removed by viewhack]: whoever reads it can still see which cookie was sent, but not its value. The page checks the copy again and reports how many of the removed kinds are left (0). A note in the log'scommentfield says what was replaced.
The file is parsed in a Web Worker, a background thread, which keeps the log and sends the page only what it draws. Measured once in headless Chrome on the site's test server: a generated 44 MB log of 20,000 requests, each with a cookie, opened in about 0.6 seconds, and the page never stopped responding for more than about 0.13 seconds. Saving its cleaned copy, with 20,200 values replaced, took about 0.7 seconds.
What a HAR file gives away
A HAR file is every request a browser tab made while the Network panel was open, written out as JSON. HTTPS protects these values on the way to the server, but the browser records them before encrypting, so they sit in the file as plain text:
- Your session cookies. With them, someone can often use the site as you, without your password or second factor, until the session ends.
- Bearer tokens and API keys in Authorization and X-API-Key headers. OAuth access tokens often last an hour, but refresh tokens and API keys can stay valid for months.
- The password you typed, if you signed in while recording, in the body of the login request.
- Everything the server sent back: your name, e-mail address, orders and messages in JSON responses.
Recent versions of Chrome and Edge save a sanitized HAR by default, without Cookie, Set-Cookie and Authorization headers, and offer the full one as "Export HAR (with sensitive data)". Even the sanitized export keeps tokens in URLs, request and response bodies and custom headers, and Firefox and Safari save the whole thing. The support engineer usually needs only the URLs, status codes, timings and error bodies. All of that stays in the cleaned copy.
How to save a HAR file
- Chrome and Edge: press F12 (Cmd+Option+I on a Mac), open the Network tab, tick "Preserve log", reload the page and do what goes wrong. Then use the download-arrow button in the Network toolbar ("Export HAR"), or right-click any request and choose one of the "Save all as HAR" items.
- Firefox: F12, Network tab, reload and reproduce the problem. Then click the gear icon and choose "Save All As HAR", or right-click a request and use the same item.
- Safari: turn on the Develop menu in Settings, Advanced; open Develop, Show Web Inspector, Network; reproduce the problem and click Export.
What it cannot do
- Replay or resend requests. It only reads the log. Nothing in it is fetched, run or rendered: an HTML or JavaScript response body is shown as text.
- Find every kind of secret. It looks for the names listed above. A credential in a header with a made-up name (
X-Acme-Thing), a JSON field calledcredentials_blob, a token inside a GraphQL query string, or a secret inside a binary or base64 body (a protobuf, an uploaded file) is not found. Personal data such as names, e-mail addresses and messages in response bodies is shown but not removed. - Promise a clean file. Read the cleaned copy before you send it, or open it here again: the secrets panel then lists what is still in it. Header sizes recorded in the file (
headersSize) are left as they were, so they no longer match the shortened values exactly. - Show timings the browser did not record. A phase marked -1 in the file (no DNS lookup because the connection was reused, say) counts as 0. Safari and some HAR exporters leave several phases out, and requests served from the cache often carry no timings at all.
- Open logs larger than the tab's memory. The whole file is parsed at once, and a parsed HAR takes roughly two to three times its size in memory. A desktop browser handles logs of tens to a few hundred MB; a phone gives a tab much less memory and may reload the page instead of showing an error. Chrome and Edge also cannot hold one text longer than about 512 MB, so a larger .har cannot be opened at all.