What is a HAR file? How to make, read and share one safely

It's plain text, so any editor will open it. It's also big. A couple of minutes on a modern web app produces hundreds of entries, and most of them are fonts, images and analytics pings that nobody will ever read.

01How to get a HAR file in Chrome, Firefox, Edge and Safari

Every browser works the same way. You open the developer tools, switch to the Network tab, reproduce the problem and export. The step people miss is keeping the log across page loads. Without it, the recording resets the moment the page navigates, and the request that broke disappears with it.

Open the Network tab before you start, then go through the steps from just before the point where things break. Ten seconds recorded around the failure beats ten minutes of browsing. The developer has to find the needle either way.

02How to open and read a HAR file

The easiest way to open a HAR file is to drag it onto the Network tab of Chrome's developer tools. It loads exactly like a live recording, and the file never leaves your machine. If you'd rather use a web page, our HAR analyzer lists the failed requests and flags secrets without uploading the file, and Google's HAR Analyzer works too.

Reading one is mostly knowing where to look. I start with failures: anything with a 4xx or 5xx status, plus status 0, which means the request never finished (blocked by CORS, an ad blocker or a dropped connection). Then I read the response body of the first failure. Errors cascade, and the first one usually explains the ones after it. After that come timings, because one request that takes 30 seconds explains "the page just hangs" better than any screenshot. Last are redirect chains, which are where login loops live.

If you have jq installed, two one-liners get you most of the way. This one lists every failed request:

jq -r '.log.entries[]  | select(.response.status >= 400 or .response.status == 0)  | "\(.response.status) \(.request.method) \(.request.url)"' session.har

And this one shows the five slowest:

jq -r '.log.entries | sort_by(-.time) | .[:5][]  | "\(.time | round)ms \(.request.url)"' session.har

03Is it safe to share a HAR file?

Not as a raw export. A HAR file can contain your cookies, authorization headers and session tokens, and anyone holding a live session token can act as you until it expires. Recent Chrome versions strip cookies and auth headers by default, but tokens in URLs, request bodies and custom headers still get through. Check the file before you send it.

This isn't a theoretical risk. Between 28 September and 17 October 2023, an attacker had access to Okta's support case system and the files that 134 customers had uploaded for troubleshooting. According to Okta, some of those were HAR files with session tokens in them, and the attacker used the tokens to hijack sessions at five customers. Those customers had done exactly what support asked them to do.

Chrome and other Chromium browsers have exported a sanitized HAR by default since version 130, which drops the Cookie, Set-Cookie and Authorization headers. The full version is still there behind a setting under the developer tools' Network preferences. That closes the most common leak. It doesn't catch an API key in a query string, a token in a custom header like X-Auth-Token, or a password inside a form post. Don't assume other browsers sanitize anything.

To clean a file yourself, this removes cookies and the usual auth headers from every entry:

jq '.log.entries |= map(  .request.cookies = [] | .response.cookies = []  | .request.headers |= map(select(.name | ascii_downcase      | IN("cookie", "authorization", "x-api-key", "x-auth-token") | not))  | .response.headers |= map(select(.name | ascii_downcase      | IN("set-cookie") | not)))' session.har > session.clean.har

Then search what's left for anything that still looks like a credential:

grep -oiE '(token|bearer|api[_-]?key|session)[^"]{0,40}' session.clean.har | sort -u

Google's open source har-sanitizer does the same thing through a web page and also handles query strings and post parameters. If you'd rather not touch a terminal at all, the HAR analyzer runs both steps in your browser and hands you a redacted copy. No sanitizer is perfect, and that includes mine. Read what's left before you trust the file.

One more habit that costs nothing: once support has the file, sign out of the account you recorded. On most apps that ends the session, and every token in the file goes dead with it.

04What should support ask for instead of a HAR file?

Usually just the one request that failed: its method, URL, status, response body and the time it happened, plus the browser console error if there was one. That's almost always enough to find the bug in server logs, and none of it can sign anyone in.

I think a whole HAR is the wrong default for most support requests. It asks a customer to run developer tools, then hands the support team a file holding that customer's live session, all to get at four facts. Those are the same four that the evidence section of a good bug report asks for.

They're also why we capture the last 50 network requests in Rebase rather than asking for HARs. Sensitive headers are removed and request text is swept for tokens before anything leaves the page, so support gets the failing request and nobody has to export a thing. Whatever tool you use, the principle holds: collect the failure, not the session.