What Is a HAR File? How to Capture, Read, and Share One Safely

The current de facto format is version 1.2. Its root is one log object with five members — version, creator, browser, pages, and entries — as set out in the HAR 1.2 specification. Each item in entries is one round trip: a full request/response pair carrying the method and URL, the request and response headers, the cookies, the query string, the postData body, the response content, and a timings block that splits the request into DNS, connect, TLS, send, wait, and receive phases. It is, in effect, a saved copy of the DevTools Network panel for a session.

A HAR is the most portable way to reproduce a network bug you cannot see. Because it freezes every request, status code, payload, and timing from the user's session, an engineer can replay the failure without remote access or a matching environment. That is also exactly what makes it dangerous. The same capture that records a failed POST /api/checkout also records the headers that authorized it — and those headers are not metadata, they are keys.

Concretely, a raw HAR can contain the Cookie and Set-Cookie headers (the session cookie itself), the Authorization header (a bearer/JWT token or Basic credentials), API keys passed in URL query strings, and any personal data typed into a form body. A live session cookie inside a shared HAR is functionally a password: anyone who replays it is signed in as the user. This is not theoretical. Cloudflare documented that the October 2023 Okta support-system breach was carried out by stealing uploaded HAR files and lifting the session tokens of administrators at Cloudflare and other organizations directly out of them. The support workflow — 'send us a HAR' — was the attack vector.

Browsers know this, which is why Chrome DevTools changed its default. Per the Network features reference, DevTools now exports a sanitized HAR that excludes the Cookie, Set-Cookie, and Authorization headers; pulling those back in is a separate, explicit 'Save all as HAR (with sensitive data)' action gated behind a settings toggle. The catch is twofold. First, the safe behavior is only the default — one wrong menu choice re-includes every secret. Second, sanitization is header-scoped: it strips three named headers, but it does not promise to remove a token embedded in a URL, a credential in a POST body, or a custom header like X-Api-Key. Firefox is blunter still. Its Network Monitor offers 'Save All as HAR', 'Copy All as HAR', and 'Import HAR' — none of which redact by default, so a single 'Copy All as HAR' can drop live cookies onto the clipboard.

The industry is now hardening the workflow rather than trusting it. As of 25 March 2026, Cloudflare ships an 'Unsanitized HAR' DLP profile that inspects HAR uploads for session cookies, authorization headers, and other credentials, then blocks the upload or redirects the user to a sanitizer that writes a tamper-evident 'sanitized' marker. When a major network provider builds data-loss-prevention specifically to catch leaking HARs, the lesson is clear: the safe-by-default design has to move earlier, to the moment of capture, not the moment of upload.

Every top-ranking HAR explainer treats safety as an after-the-fact step: export the sanitized HAR, then double-check it before you send. That ordering is the whole problem. It captures everything first and asks a human to remember to scrub second — and the Okta incident is what happens when the human forgets. The fix is to invert the order so the sensitive data never enters the artifact in the first place.

That is the wedge BugMojo is built on. Instead of dumping the full wire and hoping someone redacts it, the browser extension makes capture decide what to retain, and PII/secret redaction runs client-side, before any data leaves the browser. Sensitive headers and form values are stripped at the source, not scrubbed from a file after the fact. The result is closer to the requests you actually need — the failing POST, its status, its timing — minus the session cookie that turns a bug report into a breach. The retained network context is then attached to the bug alongside an rrweb session replay and the console output, so the report is a reproduction, not a credential-laden JSON dump.

The second half is who reads it. Because the captured context is structured, pre-sanitized fields rather than a screenshot or a raw .har, the BugMojo MCP server can hand it to an AI agent — Claude Code, Cursor — as data. The agent correlates the failed request with the replay frame and the console error and reasons about cause, without a human ever opening a HAR or risking a token in a chat window. A HAR is the right idea (freeze the network at the failure); doing it safely means deciding at capture time and making the result agent-readable.