Do HAR Files Contain Sensitive Information?

Why This Matters During Bugs

HAR files are useful because they show what the browser actually sent and received. That is also the risk. The capture usually happens while you are logged in, testing a checkout, reproducing a failed upload, or trying to prove that an API request is wrong.

Chrome now exports sanitized HAR files by default and separates them from HAR files exported with sensitive data. Google and Microsoft both document the same basic warning: browser traces can include cookies, submitted form data, and other details that should be handled carefully before sharing.

The practical rule: capture the smallest reproduction, inspect the evidence locally, then share only the redacted part needed to debug the failure.

Remove Before Sharing

• Request and response headers named Cookie, Set-Cookie, Authorization, and X-API-Key.
• Query parameters and request bodies containing tokens, magic links, OAuth codes, CSRF values, session IDs, passwords, license keys, invite codes, or reset links.
• Response bodies with account data, emails, names, billing details, internal IDs, customer records, feature flags, or private API responses.
• URLs from private tunnels, admin paths, staging domains, object-storage links, or routes that expose organization names and project IDs.
• Third-party telemetry calls if they include user IDs, distinct IDs, session replay URLs, experiment assignments, or campaign identifiers you would not paste into a bug report.

Safer Debugging Workflow

1. Open DevTools Network, clear the log, and reproduce only the failing path.
2. Prefer Chrome's sanitized HAR export first. Use the sensitive export only when headers or bodies are required for the bug.
3. Run the file through a local check before attaching it anywhere. The free DevSnoop HAR Analyzer can summarize requests and flag sensitive headers without uploading the file.
4. Replace sensitive values with stable placeholders such as REDACTED_SESSION_COOKIE so another developer can still understand the request shape.
5. Share the smallest useful slice: method, URL path, status, relevant headers, redacted payload, redacted response, and the console error that followed.

Agent Debug Bundle

For coding agents, a HAR file is often too much and still not enough. The agent also needs page structure, the reproduction step, console output, and what changed after the interaction.

My preferred bundle before editing code is compact: page summary, reproduce the action, network failures, console logs, DOM diff, then a screenshot only if layout or visual state matters. That sequence gives the agent browser evidence without dumping the whole session into the prompt.

DevSnoop exists for that loop. It lets an agent inspect the live Chrome tab and collect structured browser evidence locally, instead of passing around a large HAR file every time something breaks.

Use A HAR When

• You need to hand a support team an exact network trace.
• The bug is intermittent and you need an offline artifact.
• You need request timing, redirects, cached responses, or headers from one run.

Use a live browser-agent workflow when you are still editing the app. It is usually faster to ask the agent to inspect, reproduce, read logs and network, diff the page, and then open the right file.