How to Capture a HAR File for a Bug Report (Step by Step)

A HAR (HTTP Archive) file is a JSON log of every network request and response your browser made during a session. To capture one, open your browser's developer tools, switch to the Network tab, enable Preserve log, reproduce the bug, then right-click any request and choose Save all as HAR with content. Attaching that file to a bug report lets a developer see the exact API calls, status codes, payloads, and timings behind a failure — often without having to reproduce it themselves.

What is a HAR file?

HAR stands for HTTP Archive. It is an open JSON format that browsers and network tools use to export a full record of HTTP traffic. Each entry in the file describes one request/response pair: the URL and method, request and response headers, cookies, the payload sent, the body returned, the status code, and detailed timing (DNS, connect, wait, receive). Because it captures the network layer that a screenshot cannot show, a HAR file answers the question a screenshot leaves open: which call failed, and what did the server actually send back?

That makes it especially useful for bugs that live below the UI — a form that silently doesn't save, a page stuck on a spinner, a 500 that surfaces as a blank component, or an intermittent timeout. The visible symptom is one thing; the failing request is the evidence.

How to capture a HAR file in Chrome or Edge

Chrome and Edge share the same DevTools, so the steps are identical.

1. Open DevTools. Press F12 (or Ctrl+Shift+I / Cmd+Option+I) and click the Network tab.
2. Enable Preserve log. Tick the Preserve log checkbox at the top of the Network panel. Without it, any page navigation or redirect wipes the entries you just captured — the single most common reason a HAR ends up empty.
3. Reload and reproduce. Refresh the page so the initial load is recorded, then perform the exact steps that trigger the bug. Watch the request list fill in.
4. Export. Right-click anywhere in the request list and choose Save all as HAR with content, or click the download (↓) icon in the Network toolbar. "With content" is what includes the response bodies.
5. Save and label the file. Give it a name that ties it to the ticket, e.g. checkout-500-2026-08-04.har.

How to capture a HAR file in Firefox and Safari

Firefox: Open DevTools (F12), select the Network tab, reproduce the issue, then right-click any request row and choose Save All As HAR. Firefox preserves logs across navigation by default, but confirm the trash/clear icon wasn't clicked mid-session.

Safari: First enable the Develop menu (Settings → Advanced → "Show features for web developers"). Open Web Inspector (Cmd+Option+I), go to the Network tab, reproduce the bug, then click the Export button to save a HAR. Safari's export includes response bodies by default.

What to check before you attach a HAR file

This is the step most guides skip, and it matters more than the capture itself. A HAR file records traffic verbatim — including anything that authenticates you.

1. Assume it contains live credentials. HAR files capture Cookie and Authorization headers, bearer tokens, CSRF tokens, and any secrets in request or response bodies, all in plain text. In a widely reported October 2023 incident, attackers used session tokens found in HAR files uploaded to a vendor's support portal to hijack authenticated sessions. Treat any HAR you didn't sanitize as a password you just pasted into a ticket.
2. Sanitize or scope the capture. Strip cookies, auth headers, and personal data before sharing — either by editing the JSON, running it through a HAR sanitizer, or unchecking response bodies if the developer only needs headers and status codes.
3. Share it privately. Attach HAR files to the internal ticket, not a public issue or forum thread, and delete them once the bug is resolved.

How to read a HAR file to find the bug

You don't have to parse JSON by hand. Drag the file back into the Chrome or Firefox Network tab (or a HAR viewer) and it renders like a live session. Then work top-down:

1. Filter to failures first. Sort or filter by status and look at 4xx and 5xx responses. A 401/403 points at auth or permissions; a 404 at a wrong URL or missing resource; a 500 at a server error whose response body often names the cause.
2. Read the response body of the failing call. This is where the actual error message usually lives — the field that was rejected, the validation that failed, the stack the API returned.
3. Check timing for the slow ones. A request that succeeded but took several seconds in the Waiting (TTFB) phase explains a "the app is slow" report better than any screenshot.

How to attach a HAR file to a bug report

A HAR is strongest as one layer of evidence, not the whole report. The reports developers act on fastest pair three things: exact steps to reproduce, a screenshot or recording of the symptom, and the network + console evidence. The HAR covers the last of those in depth — but a developer still needs to know what they were supposed to see, and what they got instead.

The friction is that capturing all of this by hand — DevTools open, Preserve log ticked, HAR exported, console copied, then sanitized — is a lot of steps to ask of a non-technical reporter, and most skip it. That's the gap in-app tools close. Klavity Snap lets anyone file a bug with a right-click, and it attaches the screenshot, console errors, and network activity automatically — so the evidence a HAR file provides ships with every report, without asking the reporter to open DevTools. For a fuller breakdown of which requests actually matter, see capturing network requests for bug reports.