A HAR file is not a debug log you skim top to bottom. It's a complete recording of a browser session — every request and response, every header, every cookie, and often the full response bodies — serialized as one JSON file (HTTP Archive format). "Debug log" undersells what you're holding: it's closer to a wiretap of the tab. That's exactly why it's the fastest way to turn "it works on my machine" into something reproducible, and exactly why you can't paste it into a public ticket.
The reason it beats a screenshot of the Network panel is that it's structured data, not a picture. Every entry has the request line, the negotiated headers, the redirect chain, and a timings block that splits the wait into DNS, connect, TLS, wait (server think time), and receive. You can diff two HARs, grep them, or load them back into DevTools to inspect a session someone else captured an hour ago.
A HAR is a credential bundle disguised as a debug attachment.
Authorizationheaders, session cookies, and tokens hiding in query strings are all captured verbatim, and DevTools can be told to include response bodies too. Sanitize it and hand it over on a secure channel — never a shared doc or a screenshotted ticket.
A worked example: the login that works "sometimes"
A user reports that logging in occasionally lands them on a 401 page, then works on refresh. You can't reproduce it. They export a HAR of a failing attempt. Here's what the two POST /api/me entries show side by side:
| HAR field | Failing request | Working request (after refresh) |
|---|---|---|
startedDateTime | ...T10:00:00.020Z | ...T10:00:03.500Z |
request.headers → Cookie | (no session cookie) | session=abc123; ... |
timings.wait | 8 ms | 42 ms |
response.status | 401 | 200 |
The failing request fired 20 ms after navigation — before the redirect that sets the session cookie had resolved — so it went out with no session cookie and came back 401 in 8 ms. The refresh happened after the cookie existed. The bug isn't in the auth server; it's a front-end race firing the fetch before the login redirect completes. Nothing in a screenshot would have shown you the missing Cookie header or the 12 ms gap.
That's the general move: capture the HAR of the failing browser request, then compare it against a request you know works — a successful earlier entry, or the equivalent curl. The difference is almost always a concrete header, a redirect that went somewhere unexpected, or a timing that reveals an ordering bug. Once both requests are laid out as data instead of vibes, the delta is usually obvious in under a minute.
Cover photo by Stanislav Kondratiev on Pexels.