HAR files: capture, read, and redact before sharing

A support engineer asks you to "send a HAR file" for a checkout that keeps failing. You export one, drag it into a ticket, and move on with your day.

What you also just sent was your session cookie, your bearer token, and the full JSON body of every customer record the page loaded. HAR files record everything, and almost nobody checks them first.

Short version

• A HAR file is a JSON record of every network request the browser made while you were recording.
• Capturing one takes about thirty seconds in any modern browser.
• The waterfall view answers three questions fast: what failed, what was slow, and in what order things happened.
• HAR files contain cookies, Authorization headers, tokens in URLs, and full response bodies by default.
• Redact before you share — with a sanitizer tool, or by unchecking "include response bodies" at export time.
• Treat a HAR like a password: share it in the ticket system, not in a public channel, and delete it when the bug is closed.

---

What a HAR file is

HAR stands for HTTP Archive. It is a plain JSON file that lists every request your browser made during a recording, along with the request headers, the response headers, timing numbers, and usually the response bodies.

Open one in a text editor and you will see entries like this, trimmed down:

{
  "startedDateTime": "2026-05-27T14:32:10.482Z",
  "time": 1841,
  "request": {
    "method": "POST",
    "url": "https://api-staging.example.com/v2/orders",
    "headers": [
      { "name": "Authorization", "value": "Bearer eyJhbGciOiJIUzI1NiIs..." },
      { "name": "Content-Type", "value": "application/json" }
    ]
  },
  "response": { "status": 500, "statusText": "Internal Server Error" }
}

That is the whole idea. One entry per request, in order, with everything attached.

---

How to capture one

The steps are nearly identical across browsers. The order matters: open the panel before you reproduce the bug, or the requests will not be recorded.

Chrome and Edge

1. Open DevTools with F12, or Cmd+Option+I on macOS.
2. Go to the Network panel.
3. Tick Preserve log. Without it, a page redirect wipes the recording.
4. Tick Disable cache if you want to see what a first-time visitor sees.
5. Click the clear icon to start from an empty list.
6. Reproduce the bug.
7. Click the download icon, Export HAR. Chrome now offers two options — choose Export HAR (sanitized) unless someone has asked for the bodies.

Firefox

1. F12, then the Network tab.
2. Tick Persist Logs in the settings menu.
3. Reproduce the bug.
4. Right-click any row and choose Save All As HAR.

Safari

1. Enable the Develop menu: Settings then Advanced then Show features for web developers.
2. Open Web Inspector with Cmd+Option+I and go to Network.
3. Tick Preserve Log.
4. Reproduce, then click the Export icon.

A useful habit: after exporting, note the exact time and the account you used. A HAR with no context is much harder to match against server logs.

---

Reading the waterfall

The waterfall is the chart of horizontal bars on the right of the Network panel. Each bar is one request. Its left edge is when the request started, its width is how long it took.

You do not need to understand every colour. Three passes cover most bugs.

Pass one — status codes. Sort by the Status column. Anything that is not 2xx or 304 is a candidate.

Pass two — order. Read the requests top to bottom as a story. A common bug shape looks like this: GET /api/user returns 200, then GET /api/workspace/null/projects returns 404. The null in the second URL tells you the first response did not contain the field the code expected.

Pass three — timing. Click a slow request and open the Timing tab. The segments mean:

• Queueing / Stalled — the browser held the request. Often six-connection limits on HTTP/1.1.
• DNS lookup / Initial connection / SSL — setting up the connection.
• Waiting (TTFB) — the server thinking. Long TTFB is a backend problem, not a frontend one.
• Content Download — moving the bytes. Long download with short TTFB means the response is too big.

That split alone settles most "the app is slow" arguments. A 4.2 second TTFB is nobody's CSS problem.

---

The redaction step nobody does

This is the part of the article that matters most.

A HAR file captures headers and bodies exactly as they were sent. That means a normal HAR from a logged-in session very likely contains:

• Session cookies in the Cookie header — enough to sign in as you.
• Authorization: Bearer ... tokens.
• API keys in headers such as X-Api-Key.
• Tokens in query strings, such as ?access_token=... or a password reset link.
• Full response bodies with customer names, email addresses, phone numbers, and order values.
• The contents of any form you submitted during the recording, including passwords sent as POST data.

A HAR is not a log. It is a recording of a signed-in session. If it leaks, someone can replay it.

Four ways to redact, from easiest to most thorough

1. Export sanitized. Chrome and Edge offer "Export HAR (sanitized)", which strips cookies and Authorization headers. It is the fastest safe default. It does not remove tokens embedded in URLs or personal data in response bodies.
2. Use a HAR sanitizer. Tools such as Google's HAR Analyzer and open-source sanitizers let you load a file, strip headers and cookies, and download a cleaned copy. Prefer one that runs in the browser and does not upload your file anywhere.
3. Filter before you record. In the Network panel, type a filter such as api-staging.example.com and use "Save filtered as HAR" where your browser supports it. Fewer requests means less to check.
4. Edit the JSON. For a small HAR, open it in an editor and search for Cookie, Authorization, token, password, email, and apikey. Replace values with REDACTED. Keep the key names — a developer often needs to know a header was present.

A two-minute check before you attach

Search the file for each of these strings. If any hit returns a real value, replace it.

Authorization
Cookie
Set-Cookie
X-Api-Key
access_token
refresh_token
password
"email"

If you cannot redact it properly and the bug is urgent, say so in the ticket and share the file through a private channel with a short expiry, not a public Slack room or a public issue tracker.

Good and bad sharing

Bad: attaching a raw HAR to a public GitHub issue with the comment "network log attached".

Good: attaching a sanitized HAR to a private ticket, with a note: "Sanitized export, response bodies removed. Failing request is POST /v2/orders at 14:32:10 UTC, request ID req_8f3a91cc."

The second one is smaller, safer, and faster to act on.

---

When a HAR is the wrong tool

HAR files are large and awkward. A 30-second recording of a modern app can reach 40 MB. Before you export, ask whether something smaller answers the question.

• For a single failing request, right-click the row and choose Copy as cURL or Copy response. Paste that instead, after removing the token.
• For a timing complaint, a screenshot of the Timing tab is often enough.
• For an intermittent bug, the HAR only helps if you caught the failure during the recording. Confirm the bad request is in the file before you send it.

Collecting this evidence by hand is why many bug reports arrive with none of it. Browser-based bug reporting tools such as Crosscheck capture the network requests, console output, and environment details at the moment you report the bug, which removes the export-and-attach step from the workflow.

---

A short checklist

Before you send a HAR file, confirm:

• Preserve log was on, and the failing request is actually in the file
• You exported the sanitized version, or ran a sanitizer
• You searched for Authorization, Cookie, and token
• Response bodies with customer data are removed or the file is going somewhere private
• You noted the timestamp, the account, and the build
• You said which request is the problem, so nobody has to hunt

---

Frequently asked questions

Does a HAR file contain my password? It can. If you signed in during the recording, the login POST body may include it. Start recording after you sign in, or use the sanitized export.

How do I open a HAR file to read it? Drag it back into the Network panel of any browser DevTools. It loads as a normal request list. Google's HAR Analyzer works too, and text editors work for small files.

Why is my HAR file so large? Because it includes response bodies, including images and fonts encoded as base64. Filter to just the API domain before exporting, or export without bodies.

Is the sanitized export in Chrome safe enough? It removes cookies and Authorization headers, which covers the biggest risk. It does not remove tokens in URLs or personal data in response bodies, so still do a quick search.

How long should I keep a HAR file? Only as long as the bug is open. It is a recording of a live session, so delete it when the ticket closes, the same way you would delete a credential.