How to Capture a HAR File in Chrome, Firefox, and Edge (Without Leaking Secrets)

A HAR file is the single most useful artifact you can attach to a network bug, and the easiest one to leak credentials with. It is plain-text JSON that records every request the browser made, including headers, cookies, query strings, and frequently the request and response bodies. Captured carelessly and pasted into a public ticket, it hands a stranger everything needed to replay your logged-in session.

This guide does two things the vendor docs skip. First, the exact click path in Chrome, Edge, and Firefox. Second, an honest threat model: what the new sanitized export actually removes, what it quietly leaves behind, and the redaction pass you still owe before the file leaves your machine.

Because the format is standardized, the same .har file opens in Chrome, Edge, Firefox, Charles, and most API tooling. It is also machine-readable: the WebExtensions devtools.network.getHAR() call resolves to the same log object with a version field and an entries array, which is what an automated capture or an AI agent parses programmatically. The structure that makes HAR portable is the same structure that makes it dangerous, so capture is only half the job.

1. Open DevTools. Press F12 or Ctrl+Shift+I (Cmd+Option+I on macOS).
2. Select the Network tab. Make sure the red record dot is on.
3. Reload the page with DevTools open so requests are recorded from the first byte. Keep it open and reproduce the bug.
4. Export. Click the download/Export icon in the Network action bar and choose Export HAR (sanitized), or right-click any request and pick Save all as HAR (sanitized).

DevTools writes every request captured since you opened the panel into one .har file. Since Chrome 130 (documented 30 September 2024), the default export no longer contains Cookie, Set-Cookie, or Authorization headers. If you genuinely need them for the repro, you must opt in under Settings > Preferences > Network > 'Allow to generate HAR with sensitive data' — and then treat the result as a live credential.

Microsoft Edge ships the same Chromium DevTools, so the flow matches Chrome. Open the Network tool, reload, reproduce, then either right-click a request and choose Copy > Copy all as HAR (sanitized) or click the Export HAR (sanitized) button in the action bar. Edge's documentation (updated 3 April 2026) confirms the sanitized HAR excludes the same three header families — Cookie, Set-Cookie, and Authorization — and that including them requires the matching Allow to generate HAR with sensitive data checkbox. To inspect a teammate's file, use Import HAR file from the same action bar.

Firefox's Network Monitor hides HAR behind the toolbar overflow menu. Open it, reload, reproduce, then click the overflow menu and choose one of three verbatim items: Save All As HAR (opens a file dialog with the .har extension), Copy All As HAR (puts it on the clipboard), or Import HAR to load one back.

Here is the catch most guides miss: Firefox does not strip auth and cookie headers by default the way Chrome and Edge now do. A Firefox HAR ships your Cookie and Authorization values as captured. Manual redaction is not optional there — it is the only thing standing between the file and a session takeover.

This is the part that sinks teams. The sanitized export is a header filter, not a secret scrubber. In both Chrome and Edge it removes exactly three header families and stops there:

• Cookie — your outgoing session cookies.
• Set-Cookie — session IDs the server hands back.
• Authorization — bearer tokens and basic-auth credentials.

That blocks the most common session-hijack vector. It does nothing about secrets living anywhere else in the entry. A bearer token in a request URL or query string survives. An API key inside a POST body survives. PII and access tokens inside a JSON response body survive. The HAR spec puts request and response bodies in the same entries structure, and the sanitized pass never reads them.

Read that chart as a checklist of what you still have to do. The three lime bars are handled for you on Chrome and Edge. The three empty bars are your job, on every browser.

A repeatable pre-share pass takes about a minute and saves a credential-rotation fire drill:

1. Export the sanitized version first. On Firefox, skip nothing — assume cookies and auth headers are present.
2. Search the file for token, authorization, password, apikey, email, and your own username. Redact matches in both headers and bodies.
3. Strip URL secrets. Bearer values and session tokens hide in request.url query strings; the sanitized pass ignores them.
4. Share over a private channel — an access-controlled ticket or DM, never a public issue or pastebin.
5. Delete the file once the bug closes. If a non-sanitized HAR ever left your machine, rotate the exposed credential.

A HAR answers what did the browser send and receive. It is silent on what the user saw and did. When a request returns a 500, the HAR shows the failed call but not the click that triggered it, the DOM state at that moment, or the console error thrown on the page. You reconstruct that by hand from a screenshot and a description — which is exactly the back-and-forth a HAR was supposed to end.

This is the gap BugMojo closes. A capture pairs the failing request with the correlated rrweb DOM recording and the console output, and redacts PII client-side before anything leaves the browser. The same bundle is readable by an AI coding agent over MCP, so Claude Code or Cursor can read the request, the DOM, and the error together instead of triaging a stripped JSON file in isolation.