Before you send that HAR file, read what is inside it
“Could you send us a HAR file?” is a reasonable request — and one of the most casually dangerous file handoffs in everyday support work. A HAR file is a complete recording of a browser session: every request and response, with the cookies, authorization headers, tokens and form contents that made them work. It is exactly what a support engineer needs to reproduce your problem, and exactly what an attacker would want to replay your session. This article explains what a HAR file is, how to capture one in Chrome, Edge or Firefox, what it leaks, and how to inspect and redact it before it goes anywhere.
What a HAR file is
HAR — HTTP Archive — is a JSON format for recording HTTP traffic, standardised in the HAR 1.2 specification and exported by every major browser’s developer tools and by debugging proxies such as mitmproxy. The file holds a log object with an entries array: one entry per request, each carrying the method and full URL, the request and response headers, the cookies in both directions, the query string broken out as parameters, any POST body, the response’s status, size and content type, and timings broken down by phase — DNS, connect, TLS, send, wait, receive.
In other words, it is not a screenshot of the problem; it is the problem, replayable. Anything that consumes HTTP traffic works with the format — browser tooling, performance analysers, support engineers, and increasingly, agents: the REA stack covered in can AI agents reverse-engineer your app? reads HAR captures natively, because for many apps the API traffic explains more than the code does. That usefulness is precisely why the file deserves a read before it deserves a send.
Why support desks and vendors ask for one
Because it ends arguments. “The page is slow” becomes a waterfall with named requests and timings. “The API fails” becomes the exact request that returned 500, with the exact payload and the exact headers. “It works on my machine” stops mattering, because the recording is from your machine, your network, your account, at the moment it broke. A good support engineer can do more with one honest HAR file than with a week of screenshots and recollections.
That is also why the request is so often forwarded without thought. The ticket says “attach a HAR”, the user exports one in thirty seconds, and the file — recorded while they were logged in, doing real work — travels: into a ticket system, an email thread, sometimes a public forum or a shared drive, accumulating copies at every hop. Nobody in that chain is careless exactly; the format simply hides what it contains. A .har file looks like inert diagnostics. It is closer to a keyring.
How to capture one in Chrome, Edge or Firefox
In Chrome or Edge: open the page, press F12 for DevTools, and go to the Network panel (the Chrome DevTools network reference documents every control). Make sure the red record button is on and tick Preserve log if the problem spans a navigation. Reproduce the problem once, end to end. Then right-click any request in the list and choose Save all as HAR with content (Edge phrases it as saving the network log). In Firefox the flow is the same shape: DevTools → Network, reproduce, right-click → Save All As HAR.
Two capture habits matter more than any setting. First, record the shortest session that shows the problem: every extra minute of browsing is extra traffic — and extra secrets — in the file, including whatever other tabs and background requests were doing. Second, if you can, reproduce the problem in a fresh browser profile or a private window, signed in only to the service in question. A capture from a clean profile contains that one session and nothing else: no banking tab, no webmail, no other apps’ tokens riding along.
What it leaks
Your session, first of all. The Cookie and Set-Cookie headers and the cookie lists carry your session identifiers, and most session cookies are bearer credentials in the plainest sense: whoever presents one is treated as you until it expires or is revoked. The Authorization header adds bearer tokens and sometimes Basic credentials. Nothing in the format marks these as special; they are just headers, recorded faithfully.
Then the things nobody thinks of as headers. Tokens ride in URLs all the time — API keys, password-reset and email-verification links, signed download URLs, OAuth callbacks — and the HAR records the full URL plus the query string broken out for easy reading. POST bodies carry whatever the forms carried: the password you logged in with during the capture, profile edits, messages, personal data. Response bodies can carry the same class of data coming back. A HAR file from a real session is, in effect, a partial transcript of your account — which is why tools that read network traffic on the wire, like the PCAP Analyzer, and tools that read it in the browser, like this one, are built to show the credentials plainly so you can see what you are holding.
Inspect and redact it before you send
So: open the file before anyone else does. That is what this site’s HAR File Analyzer is for — drop the .har into the page and it is parsed locally, on your device, never uploaded, with sensitive values masked by default: Authorization, Cookie and Set-Cookie headers, every cookie value, and any header, query parameter, form field or JSON key whose name looks like a token, key, secret, session or password. Skim the summary and the slowest and largest requests; check what hosts appear — a capture sometimes contains traffic from sites you were not even looking at — and use the “show values” toggle, on your own screen only, if you need to confirm what is really in there.
Then download the redacted .har and send that instead. Redaction keeps the structure a support engineer needs — same entries, headers, URLs as shapes, statuses and timings — and replaces the credential values with the literal text REDACTED, in headers, cookies, query strings, form data and JSON bodies alike. One limit is printed on the tool and repeated here: a POST body that is neither JSON nor ordinary form data cannot be parsed safely, so it is carried over unchanged — if your capture contains such a body, read it yourself before the file travels. The masked CSV summary exists for the same reason: it is the file you attach when the engineer asks for “just the list of requests”.
What redaction cannot do
Redaction removes the keys; it does not remove the map. A redacted HAR still shows your hosts and endpoints, your parameter names, the shape and size of responses, the sequence and timing of calls — a working sketch of your application’s API, which may itself be information you do not publish. It also cannot recall copies: once a raw file has gone into a ticket system or an inbox, redacting your copy changes nothing about theirs. Share the redacted file through the private channel the vendor gave you — the ticket itself, not a public post or a public file link — and ask, in the ticket, for the file to be deleted when the case closes. Reputable support organisations do this routinely; asking costs nothing.
And if a raw, unredacted HAR has already escaped — sent to the wrong address, attached to a public issue, left in a shared folder — treat the session as exposed, because it is: sign out of the service (which usually invalidates the session server-side), sign back in, and rotate any API keys that appeared in it. That is the same rule as for any leaked credential, and it is the reason the small print on this site’s other file tools is identical — the Binary File Inspector reads executables locally for the same reason this page reads captures locally: the files that most need inspecting are exactly the files that should not be uploaded to do it.