DebuggingIntermediate4-6 min reference
HAR File Analysis
A HAR (HTTP Archive) is a JSON capture of every request a page made — the perfect attachment for a hard-to-reproduce bug, because the developer sees exactly what happened. This sheet covers what's inside, how to read it, and the one thing you must do before sharing. Use the HAR viewer utility (linked below) rather than reading raw JSON.
Capturing one
DevTools → Network → (Preserve log on) → reproduce → right-click → Save all as HAR. Firefox and most proxies (Charles, Proxyman) export HAR too.
What's inside
| Field | Holds |
|---|---|
entries[] | One per request |
request | method, url, headers, query, postData |
response | status, headers, content (body), size |
timings | blocked, dns, connect, wait (TTFB), receive |
startedDateTime | when each request fired |
serverIPAddress / cache | host + cache use |
How to read it
- Sort/scan for non-2xx statuses first.
- Check
timings.waitfor slow backends;receivefor big payloads. - Inspect the request of a failing call — right payload/headers/auth?
- Inspect the response body for the actual error.
- Look for duplicate or waterfall requests hurting performance.
⚠ Before you share it
A HAR contains everything — auth tokens, cookies, session ids, request/response bodies with PII. Sanitise it (the viewer/tools can redact) or share only the relevant entries. Never paste a raw HAR into a public ticket.
Common mistakes
- Sharing an unsanitised HAR → leaking live tokens/PII.
- Capturing without Preserve log, so the redirect/login requests are missing.
- Reading raw JSON instead of a viewer (slow, error-prone).
- Sending a HAR with no note on which entry/timestamp is the bug.
// Related resources