HAR Files Explained: Debug Network Traffic & Redact Sensitive Data (2026)

When a page is slow or an API call fails, the fastest way to show someone exactly what happened is a HAR file — a complete recording of every request your browser made. It is also one of the most quietly dangerous files a user can attach to a support ticket, because it contains your session cookies, API tokens, and sometimes passwords. This guide covers both sides: how to use HAR files to debug anything, and how to strip them clean before anyone else sees them.

1. What Is a HAR File?

HAR stands for HTTP Archive. It is a standardized JSON format that records every HTTP transaction a browser performed while recording was on: the URL, method, status code, all request and response headers, timings broken down by phase, sizes, and — if content capture was enabled — the full bodies. Because the format is standardized, a capture from Chrome opens perfectly in Firefox's DevTools, in analysis tools, and in your teammate's editor.

Support engineers at CDNs, hosting companies, and API providers routinely ask for HAR files because a single file answers the questions a screenshot cannot: Was it a 403 or a 500? Which request was slow? Did the browser even attempt the call? What cache headers came back?

2. Capturing One in Every Browser

The workflow is identical in spirit everywhere: open the network panel, start recording, reproduce the problem, stop, export.

• Chrome / Edge: DevTools (F12) → Network tab → check "Disable cache" → reproduce the issue → right-click any request → "Save all as HAR with content", or use the export (↓) icon.
• Firefox: DevTools → Network tab → reproduce → gear icon → "Save All As HAR", or right-click → Save All As HAR.
• Safari: First enable the Develop menu (Settings → Advanced), then Develop → Show Web Inspector → Network tab → Export button in the top-right.

Two capture rules make HAR files actually useful. First, start recording before the failing action — a capture that begins after the bug occurred misses the failing request. Second, keep the capture scoped: clear the network log, reproduce only the problem once, then export. A 10,000-entry capture buries the signal and makes redaction harder.

3. What's Inside: The JSON Structure

A HAR file is one JSON object with a log root. The parts you will actually use:

{
  "log": {
    "version": "1.2",
    "creator": { "name": "Chrome", "version": "126" },
    "entries": [
      {
        "startedDateTime": "2026-08-26T10:14:03.221Z",
        "time": 342.19,
        "request":  { "method": "POST", "url": "https://api.example.com/login",
                      "headers": [ { "name": "Authorization", "value": "Bearer ey..." } ],
                      "postData": { "text": "{\"user\":\"ana\"}" } },
        "response": { "status": 401,
                      "headers": [ { "name": "Set-Cookie", "value": "session=..." } ],
                      "content":  { "text": "{\"error\":\"bad credentials\"}" } }
      }
    ]
  }
}

Each entry is one request. time is total duration in milliseconds; inside timings you also get the phase breakdown (DNS, connect, TLS, wait, receive). Note how much sensitive surface is visible in this one example: an Authorization header, a session cookie, and a request body containing a username. That is one login attempt. Now imagine a capture of a whole dashboard session.

4. Reading the Waterfall Timeline

The fastest diagnosis technique is reading the waterfall — the horizontal bars showing when each request ran and where its time went:

• Long DNS or connect bars — resolver or network problems, not your app.
• Long TLS bars — certificate or handshake issues, often with new domains or misconfigured CDNs.
• Long "waiting" (TTFB) bars — the server took the time. This is where backend profiling starts.
• Long download bars on small files — bandwidth or throttling; check response sizes.
• Requests starting late in a chain — blocked on another request; look for the dependency that delayed them.

Sort by "time" descending and the top five rows usually tell the whole story. Sort by status and group the 4xx/5xx rows to find the actual failures inside an otherwise-green capture.

The waterfall's numbers come from the timings object on each entry, and every phase points at a different owner of the problem:

Phase (waterfall label)	What it measures	Where the fix usually lives
Queueing / stalled	Time spent waiting for a free connection, disk slot, or higher-priority request	Too many concurrent connections; the HTTP/1.1 six-per-host limit; throttled low-priority resources
DNS lookup	Resolving the hostname to an IP address	Resolver latency; missing prefetch on third-party hosts
Initial connection	TCP three-way handshake	Network path; missing connection reuse; cold start to a new origin
SSL / TLS	Certificate exchange and key negotiation	Certificate chain size; missing session resumption; TLS 1.2 vs 1.3 on new connections
Waiting (TTFB)	Request sent until the first response byte: server processing plus any proxy hops	Application code, database queries, cold caches, origin placement
Content Download	First byte until the last byte of the response body	Payload size; compression (check Content-Encoding); bandwidth or throttling

A useful discipline: for the single slowest request on the page, name the dominant phase out loud before touching code. "TTFB is 1.8 s and everything else is milliseconds" versus "TTFB is 120 ms but download takes two seconds" send you to completely different fixes — backend profiling on one side, payload size and compression on the other — and the waterfall settles the argument in seconds.

5. The Danger: What HAR Files Leak

Here is the part most users never hear: a HAR file is a credential dump waiting to be attached to a ticket. Depending on the session, it routinely contains:

• Authorization headers — Bearer tokens, API keys, JWTs that grant live access until they expire.
• Cookie headers — session cookies that can hijack a login without a password.
• Set-Cookie responses — the same session material from the server side.
• Request bodies — passwords typed into login forms, personal data in API payloads.
• Response bodies — other users' data if you were testing admin views, plus internal API shapes attackers love.

Security teams treat unredacted HAR files the way they treat password dumps, because functionally they are one. The attack is not hypothetical: anyone holding your session cookie can typically impersonate you to the application without ever needing your password.

6. Redaction: What to Strip Before Sharing

Before a HAR file leaves your machine, strip at minimum:

1. Authorization headers (request side) — Bearer tokens, Basic auth, API keys in custom headers like X-Api-Key.
2. Cookie and Set-Cookie headers — both directions.
3. All request and response bodies — unless the bug is literally in a body, sizes and statuses usually suffice for diagnosis.
4. Custom auth headers specific to your stack — X-Auth-Token, X-CSRF-Token, anything that looks like a credential.

Manual redaction (opening the JSON in an editor and deleting) works but is error-prone at scale — one missed header in entry 4,000 of 4,000 is enough. A redaction tool that processes the file structurally is faster and safer. Our HAR File Analyzer & Redactor does this locally: it strips the credential header families, removes bodies on request, and hands you a clean download — and because it runs in the browser, the sensitive original never leaves your device in the first place. That last property matters more than it sounds; uploading an unredacted HAR to a random web tool just moves the leak.

Advanced redaction: regex patterns and partial body edits

Header stripping covers most tickets, but bodies and URLs sometimes have to survive redaction because the bug lives inside them — a malformed JSON payload, a mis-serialized form field, an image endpoint returning the wrong bytes. In that case you need targeted redaction instead of wholesale deletion. A practical pattern set for text-level redaction of bodies, URL query strings, and leftover headers:

What to catch	Example pattern	Typical match
Bearer / JWT-style tokens	eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+	JWT header.payload.signature blobs anywhere in text
Long hex secrets	\b[0-9a-fA-F]{32,}\b	API keys, session ids, hashes embedded in URLs
Credential query parameters	(token|key|secret|password|sig)=[^&\s"]+	Values like ?token=abc123 in URLs and redirects
Email addresses	[\w.+-]+@[\w-]+\.[\w.]+	PII in support payloads and error bodies
Credit-card-shaped digit runs	\b(?:\d[ -]?)+\b with a 13–19 length check	Payment test data pasted into form bodies

For JSON bodies, prefer structural edits over string substitution: parse the body, walk it recursively, replace sensitive fields by name (password, token, authorization, card, ssn), and re-serialize. A hybrid works well in practice — replace the sensitive string values with "[REDACTED]" while keeping the surrounding structure, keys, and non-sensitive values intact. The receiving engineer can still reproduce the shape of the bug (which field was empty, which array was mis-nested) without ever seeing the secret that rode along with it. Whichever method you use, keep a checklist of exactly which patterns and fields you applied; a second pass on the exported file is where mistakes get caught.

7. The Safe Support-Ticket Workflow

1. Reproduce cleanly: clear the network log, trigger the bug once, stop recording.
2. Analyze first yourself: open the file in a local analyzer — often you will spot the failing status or slow request and solve it without any ticket.
3. Redact: strip auth headers, cookies, and bodies. Keep URLs, statuses, timings, and cache headers — that is what support actually needs.
4. Sanity-check the export: search the redacted file for Authorization, token, and cookie. Zero hits means it is safe.
5. Attach with context: timestamp of the failing action, expected vs actual behavior. Support resolves scoped, redacted captures in a fraction of the back-and-forth.

The same discipline applies to related artifacts: environment files and log files carry credentials too — see why you should never upload .env files online, and for stripping credentials from server logs, the Log File Anonymizer applies the same local-first redaction idea to log streams. To scan any snippet for accidentally included credentials before it leaves your machine, the Secret Scanner detects key patterns client-side.

8. HAR vs Chrome Performance Traces: Picking the Right Artifact

Developers often grab a HAR when the bug is actually rendering-side, or a Performance trace when the bug is network-side. The two recordings overlap but answer different questions:

Question you are answering	HAR file	Performance trace
Which requests failed, with what status and headers?	Yes — full fidelity	No — timing summaries only
What cookies and tokens did the browser actually send?	Yes	No
What did the main thread do between frames?	No	Yes — scripting, layout, paint, long tasks
Which function caused a 300 ms interaction delay?	No	Yes
Can support analyze this without Chrome?	Yes — any HAR tool	No — the trace viewer is Chrome-centric
Typical file size for a 30-second capture	Hundreds of KB to a few MB	Often 10–100 MB

Rule of thumb: if the complaint mentions a status code, an API, "the network tab", authentication, or a third-party script, capture a HAR. If the complaint mentions jank, a slow interaction, a blank frame, or a layout shift, record a Performance trace. When the truth sits in between, take both — start the Performance recording, reproduce once, and export the HAR from the same session so the request timeline and the main-thread timeline describe the same run. The HAR remains the artifact you attach to tickets; traces are too heavy, too tool-specific, and (because they include page URLs and sometimes script source) too sensitive to share casually.

9. Reproducing Anywhere: Copy as cURL and HAR Import

A HAR entry is not just evidence — it is a replayable request. Two workflows turn entries into reproductions you can run anywhere.

Copy as cURL from a HAR entry

1. Right-click the failing request in the Network panel → Copy → Copy as cURL (bash or PowerShell flavor, matching your shell).
2. Paste into a terminal. You now have the exact headers, cookies, and body the browser sent — including the ones that broke.
3. Add -v to stream full response headers, or --compressed to see how sizes change when decompression is handled for you.

Because the command embeds live cookies, treat a pasted cURL string with the same secrecy as the HAR itself. Before pasting one into a chat window or ticket, delete the Cookie and Authorization headers — the receiving side almost never needs your production session to reproduce a server-side bug, and when it does need credentials, a short-lived test token beats shipping a real session across a support channel. When you want the request in application code instead of a shell, our cURL to Code converter re-expresses the command as a client snippet; swap in your own credentials before running it.

Importing a HAR into API clients

Postman and Insomnia both import HAR files and reconstruct collections from them: Postman's Import dialog accepts HAR directly and creates one request per entry, preserving methods, bodies, and many headers; Insomnia offers the same via Import → HAR. Two cautions apply to both:

• Headers arrive as-is. The imported requests carry the captured Authorization and Cookie values. Delete or overwrite them before syncing the collection to a shared workspace.
• Bodies and volume pile up. A dashboard capture imports hundreds of GET requests nobody will ever replay. Import, then prune to the two or three endpoints you are actually debugging.

The same idea runs headless in CI: export a HAR of a known-good run in staging, replay selected entries as cURL or generated client calls against the candidate build, and assert on status codes and response shapes. That catches contract breaks — a renamed field, a newly required header, a fresh 403 — that unit tests never see. For verifying the authenticity half of those requests on the server side, the webhook signature verification guide covers the complementary pattern.

10. Three Diagnosis Case Studies

Abstract advice sticks better with concrete captures. Three anonymized HARs, each diagnosed from the file alone:

Case A: "The dashboard takes eight seconds on first load"

Sorted by time, the slowest entry was not the main document (310 ms) but an analytics POST at 6.4 s with a 6.1 s waiting phase. The waterfall also showed every first-party XHR queued behind it on HTTP/1.1 — the browser's six-connections-per-host limit had been consumed by the blocking third-party call. The fix was to defer the analytics beacon until after first paint using sendBeacon. Second-load time dropped under two seconds. The lesson: look at what other requests are waiting on, not only at what is slow by itself.

Case B: "The page looks blank for three seconds, but TTFB is fine"

Document timing was healthy (TTFB 140 ms). The waterfall showed a 1.9 MB stylesheet from the same origin downloading over 900 ms, followed by a 2.1 MB blocking script that did not start until the stylesheet finished — over two seconds of serialized render-blocking work before first meaningful paint. The fixes were all network-side: enable compression (no Content-Encoding header was present), set long cache lifetimes on fingerprinted assets, and load the script with defer. This is the render-blocking signature: healthy waiting bars, fat download bars, everything serialized behind the biggest asset.

Case C: "One user gets a 403 on export, nobody else does"

The HAR exported from the affected user showed the failing request carrying an Authorization: Bearer header issued three days earlier, while a working capture from another user carried a freshly minted token. The app renewed tokens on its profile endpoint, but the export flow used a cached client instance that never picked up the refresh. There was no server bug at all. Note what made this diagnosable: the status code, the header age, and a comparison between two captures — precisely the metadata that redaction must keep (header names and structure) while removing the values themselves. Redact by structure, not by deleting whole sections, or you destroy exactly this kind of evidence.

11. HARs as Personal Data: Privacy and GDPR

Treat every unredacted HAR as personal data until proven otherwise. Under GDPR and similar regimes, a capture from a real user session routinely contains material covered by data-protection rules:

Data in the HAR	Why it counts as personal data
Session cookies and bearer tokens	They identify a person to the application, and possession equals impersonation
Email addresses in bodies or URLs	Direct identifiers
IP addresses visible in request context	Classified as personal data in the EU
Names, account numbers, admin-view payloads	Third-party data beyond the person reporting the bug
Full request and response bodies	Free text that may contain anything the user pasted or the app returned

Practical consequences for teams. A HAR uploaded to a vendor's web tool is a disclosure to that vendor and their subprocessors — the same calculation you would make for any other customer-data export. Prefer tools that process captures locally; the HAR File Analyzer & Redactor never uploads the file, which keeps the disclosure surface at zero. When a capture must go to an external party anyway, log it in your data-processing records the way you would for a database export, delete ticket attachments on a schedule (support platforms retain them far longer than anyone expects), and never archive unredacted captures "just in case" — the debugging value evaporates as soon as the session rotates, but the leak does not. The same reasoning is why .env files must stay off online tools, and why log streams get the Log File Anonymizer treatment before they leave a machine.

Conclusion

HAR files are the most complete debugging artifact a browser can produce — and, unredacted, one of the most dangerous files you can share. Capture scoped, read the waterfall, strip the credentials, and you get all of the diagnostic power with none of the exposure. The pattern to remember: analyze locally, redact structurally, share deliberately.

Frequently Asked Questions

What is a HAR file?

A HAR (HTTP Archive) file is a JSON log recording every network request and response a browser made while recording: URLs, headers, timings, sizes, and status codes. Support teams and developers use it to debug slow pages and failed requests.

How do I capture a HAR file in Chrome?

Open DevTools, go to the Network tab, check Disable cache, reproduce the problem, then right-click any request and choose Save all as HAR with content, or use the export arrow icon.

Are HAR files safe to share?

Not without redaction. HAR files capture Authorization headers, cookies, API keys, and sometimes full request and response bodies. Sharing an unredacted HAR can leak live session credentials.

What sensitive data does a HAR file contain?

Commonly: Authorization and Cookie headers, Set-Cookie responses, API keys in custom headers, CSRF tokens, and full payloads if content capture was enabled. Anything your browser sent or received is in the file.

How do I redact a HAR file before sharing?

Use a client-side HAR redactor that strips Authorization, Cookie, and Set-Cookie headers plus custom headers you name, and optionally removes all bodies. Browser-based tools do this locally so the file never leaves your machine.

How do I open and read a HAR file?

Drag it back into the Network tab of browser DevTools, or use a browser-based HAR analyzer that shows a request table with statuses, sizes, and a waterfall timeline without uploading the file anywhere.

What is the waterfall timeline?

A bar per request showing when it started relative to page load and how long DNS, connection, TLS, waiting, and download took. Long waiting bars point at slow servers; long DNS bars at resolver problems.

Do HAR files work across browsers?

Yes. HAR is a standardized JSON format, so a capture from Chrome, Firefox, Safari, or Edge opens in any tool that reads the format.