Inspect HAR Files Without Uploading Them Anywhere
HAR captures are gold for debugging - and full of cookies, tokens, and personal data. Here’s how to summarize and triage them locally.
Part of the Developer Privacy Workflows series.
Someone drops a HAR in Slack with “API is slow.” Helpful. Also slightly terrifying. A HAR is basically a diary of requests: URLs, headers, sometimes bodies, often cookies and bearer tokens. Uploading that diary to a random “HAR viewer” site is how staging credentials wander into places they shouldn’t.
Why HARs deserve kid gloves
Browsers record what they saw. That can include Authorization headers, session cookies, password reset URLs, internal hostnames, and query strings with emails or account ids. Even when bodies are truncated, headers alone can be enough to hijack a session.
Treat a HAR like a password dump until you’ve scrubbed it. If you need to share, redact first with Secrets Redactor or strip cookies in DevTools before export.
A local triage flow that works
- Keep the file on disk. Don’t attach it to a public ticket tracker if you can avoid it.
- Open HAR Summarizer and load the capture in-browser for status codes, timings, and host breakdowns.
- For incident-shaped work (timeouts, spikes, failing endpoints), use HAR Incident Studio to narrow the story.
- Note the slowest calls and the first 4xx/5xx. That’s usually enough for a first hypothesis.
- Only then share a summary - hosts, paths, timings - not the raw file.
What to look for before you blame the backend
- Waterfall gaps: is the browser waiting on a third-party script?
- Duplicate calls: React double-fetch or misconfigured polling.
- Payload size: JSON blobs that should be paginated.
- TLS or CORS failures that look like “API down” from the UI’s point of view (more on CORS in CORS errors explained).
Sharing rules that save careers
If a vendor support team demands a HAR, ask whether a scrubbed version is acceptable. Remove Cookie, Set-Cookie, and Authorization. Replace tokens with REDACTED. Prefer environment-specific captures over production when you can reproduce.
Same instinct as JWT debugging: decode locally, don’t paste secrets into cloud toys. The JWT sibling of this advice lives in decode JWTs safely.
Checklist before the file leaves your laptop
- Cookies stripped or redacted?
- Auth headers gone?
- Internal-only hosts renamed if the recipient doesn’t need them?
- Filename free of customer names?
- Summary written so most people never need the raw capture?
Reproduce without shipping the raw HAR
Often you don’t need the full capture in someone else’s hands. Extract:
- Failing URL path and status code.
- Timing breakdown (DNS, connect, TTFB, download).
- Request size and response size.
- Whether the failure correlates with a third-party host.
Paste that summary into the ticket. Keep the HAR in a secure internal drive with access limited to the people debugging. Expire it when the incident closes.
DevTools hygiene before export
Chrome lets you block cookies or sanitize in some workflows - still verify the exported JSON. Search the file for Bearer, cookie, eyJ (JWT prefix), and internal hostnames. If your editor can run a quick redact macro, use it. Secrets redactors exist for a reason; use them before the file leaves the machine.
Also prefer “preserve log” captures scoped to the failing navigation rather than an hour of browsing that includes your email inbox requests.
Incident roles
One person owns the raw HAR. Others get summaries. That reduces accidental re-sharing. If a vendor must see headers, create a scrubbed derivative and name the file scrubbed so nobody confuses it with the original.
After the firefight, write down which headers were necessary for diagnosis. Next time you’ll scrub faster and argue less.
Field notes from teams who shipped this
The pattern that keeps showing up: write the constraint first, then the steps, then the failure modes. Teams that only publish happy-path screenshots create tickets. Teams that document the ugly path create trust.
Schedule a short review ninety days after publishing. Check whether product UI names still match, whether linked tools still exist, and whether support still hears the same questions. Update the page or merge it. Standing still is how useful posts become interchangeable again.
If you adapt this article for internal wikis, keep the examples tied to your stack names. The moment you generalize back to “best practices for organizations,” you’ve started erasing the specificity that made the piece worth saving.
Legal and client constraints
Some contracts forbid sending customer traffic metadata to any subprocessors without approval. A HAR is metadata-rich. Even scrubbed, it can reveal integration partners and traffic volumes. When in doubt, keep captures inside the customer's tenant tools or your approved VPC analyzers.
If you teach juniors with real HARs, use synthetic environments. Production teaches bad habits about what “sample data” means.
Also consider retention: delete local HAR folders after incidents. Laptop backups can resurrect sensitive captures months later when you least want them in a restore set.
Pair HAR discipline with the same instincts you use for online converters - convenience is not a policy exception by itself.
Choosing local tooling
Browser summarizers are enough for many incidents. Deep packet or backend APM tools still matter for server-side truth - HARs only show what the browser saw. Use both when the symptom could be either tier. Write the handoff format your team expects so the next on-call isn’t inventing structure at 2 a.m.
If your company standardizes on one scrub script, keep it in the engineering repo with a one-line README. Tribal Knowledge in someone’s head is how raw HARs escape during vacations.
FAQ
Does Chrome sanitize HAR exports?
Not enough to relax. You still get sensitive headers unless you consciously scrub.
Our HAR is huge. Now what?
Filter to the problem window in DevTools before export, or summarize locally and attach stats instead of the full JSON.