How to Get a HAR File From a Tester (and Skip the Ask)

To get a HAR file from a tester, ask them to open DevTools, switch to the Network tab, reproduce the bug, then export with "Save all as HAR with content". That works, but most testers will not do it. Here is the exact request to send, the redaction step you must not skip, and a way to stop asking at all.

What a HAR file is and why developers ask for it

A HAR (HTTP Archive) file is a JSON log of every request the browser made: URL, method, status, headers, timings and, optionally, response bodies. When a bug report says "the pay button does nothing", the HAR shows whether the call returned a 500, never left the browser, or came back with a payload the UI could not parse.

It answers the question a screenshot cannot: what did the server actually say? If you are stuck on a report you cannot reproduce, the network log is often the missing piece. We cover the wider checklist in Cannot Reproduce a Bug From a User Report? Do This.

The steps to send your tester

Paste this, adjusted to your browser:

1. Open the page where the bug happens, then press F12 (or Cmd+Option+I on Mac).
2. Click the Network tab.
3. Tick Preserve log so requests survive a page change.
4. Click the clear icon, so the file only holds the bug.
5. Do the steps that trigger the problem, once.
6. Right-click any row and choose Save all as HAR with content (Chrome and Edge) or Save All As HAR (Firefox). Safari has an Export button in the Network tab.
7. Send the file with the time the bug happened.

Seven steps is the problem. A tester who found a bug in two minutes will not follow them. Expect a fraction of reports to come back with a HAR attached, and the rest with "it just doesn't work".

Redact before you share it

A HAR with content contains whatever the browser sent and received: cookies, bearer tokens, session IDs, emails, sometimes passwords in form posts. Treat it like a credential.

• Ask testers to use a test account, never a real one.
• Strip Authorization and Cookie headers before the file goes into a public issue.
• Rotate any token that appeared in a file you cannot account for.
• Store HAR files in your private tracker, not in a public GitHub repository.

If you handle testers in the EU, recorded traffic is personal data too. Our piece on session replay and GDPR covers what to mask.

What to read first in the file

Do not scroll the whole thing. Load it in the DevTools Network tab (import the HAR) and:

• Filter by status: anything 4xx or 5xx, or a request stuck on "pending".
• Sort by time to spot the slow call that froze the UI.
• Open the failing request and compare the request payload with what your API expects.
• Check the order of requests: a missing call usually means a front-end bug, a failed one a back-end bug.

Pair it with the console log from the same moment. A failed request plus an uncaught exception tells the whole story. For mobile apps, the same idea applies: Attach Logs to a Flutter Bug Report shows how to capture errors and network calls in Flutter.

Stop asking testers for HAR files

The better fix is to not depend on the tester. If your feedback tool captures the console, the network calls and a session replay at the moment of the report, the developer gets the HAR-grade context without a single instruction sent. That is what Tracebird does for web and Flutter apps: the report arrives with the annotated capture, console logs, network calls and replay attached, and testers never need an account.

Keep the manual HAR recipe for the rare case where you need a full trace from a customer on a tool you do not control. For everything else, capture the context automatically and spend the saved back-and-forth on the fix.