A .har file usually arrives when someone can't explain a bug cleanly. The page stalled. A save action spun forever. Checkout failed once, then worked on refresh. Instead of a screenshot and a vague comment, they sent the browser's network log.
That file can be useful fast, or useless fast. A lot of guides stop at “open DevTools and import it.” That's only the first inch of the job. If the capture missed redirects, dropped response bodies, or stripped auth details, opening it won't get anyone closer to a fix.
What Is a HAR File and Why You Have One
A user reports, "the page just spins," but the screenshot looks normal and the bug still will not reproduce on your machine. The HAR file is usually the first artifact that shows what happened on the wire.
A HAR file is an HTTP Archive saved as JSON. It captures the browser's network session: requests, response headers, cookies, redirects, status codes, and timing data. In practice, teams pass HAR files around because they preserve the exact sequence of network events behind a broken checkout, failed login, CORS error, or slow API call.
That does not mean every HAR is immediately useful.
A file can open fine and still block real debugging. Response bodies may be missing because the capture started too late, the browser stripped sensitive content, or the export came from the wrong tab. The log may also be incomplete if the user forgot to preserve network activity across redirects or captured after the failure already happened. Those are the cases that waste time. You can view the file, but you still cannot explain the bug.
Treat a HAR as network evidence tied to a specific session. It helps answer concrete questions: which request failed, what the server returned, whether auth state changed, and where time was spent before the UI broke. That is the gap many "how to open HAR file" guides miss. Opening the file is easy. Getting to a fix depends on whether the capture includes the failing request, the right headers, and enough timing detail to trace cause and effect.
If you need a quick refresher on terms used in bug reports and request analysis, this web debugging glossary is a useful reference.
Three Ways to Open and View a HAR File
A HAR file usually gets opened when something already failed. The useful question is not which app can display it. The useful question is which view will help you confirm the failing request, spot a bad redirect chain, or prove the response body was never captured.
There are three practical ways to open a HAR file. Pick based on the job. DevTools is best for tracing behavior. An online viewer is fine for a quick, low-risk check. Raw JSON in an editor is best when the UI hides the detail you need.
Open It in Browser DevTools
Start here if you need to debug anything real.
Chrome, Edge, and Firefox can import a HAR into the Network panel and rebuild the request list in a format you can work with. Safari can do it too after developer features are enabled. This view matters because debugging usually depends on sequence, timing, and request relationships. A text editor cannot show that well.
DevTools is the strongest option for a few reasons:
- You get the waterfall view. That makes it easier to see redirects, parallel requests, blocking time, and where the page started to stall.
- Each request is grouped into tabs.
Headers, cookies, payloads, previews, and timing details are easier to inspect than raw nested JSON. - Filtering is fast. You can isolate
XHRandFetch, search by path, or scan only 4xx and 5xx responses. - Missing data is easier to notice. If a request has no body, no content, or suspiciously few entries, the import often makes that obvious right away.
If the goal is to get from "I opened the file" to "I know what broke," this is usually the right path.
Use an Online HAR Viewer
Use this when you need a fast read and the file does not contain sensitive data.
Online viewers are good for opening a HAR without touching local browser tooling. Drag in the file, scan the request list, confirm the export is readable, and decide whether it is worth deeper analysis. That is useful in triage, especially when a teammate only needs to verify that the failing endpoint is present at all.
This method works best for lightweight review:
| use case | why it helps |
|---|---|
| quick triage | fast way to confirm the file opens and contains requests |
| sharing with non-dev reviewers | simpler interface than DevTools for a first pass |
| checking whether a file is incomplete | easy to spot obviously missing entries or blank content fields |
The trade-off is privacy and depth. HAR files can include auth headers, query params, cookies, and response payloads. If the capture came from a production session, uploading it to any third-party viewer may be the wrong call.
Open the Raw JSON in a Code Editor
Open the file in VS Code, Cursor, or another editor when you need exact values, not a visual summary.
A HAR file is JSON. That makes direct search useful for checking whether a header exists, whether content.text is empty, whether a request was redirected, or whether the export contains the endpoint everyone assumes is missing. This is often the fastest way to prove the problem is the capture itself, not the viewer.
Raw JSON is good for:
- Finding exact strings like endpoint paths, token names, and server error messages
- Inspecting structure such as
log,pages,entries, and nested request or response fields - Confirming whether bodies were captured before spending time on a viewer that cannot display data that is not there
- Comparing requests side by side when you need to diff payload shape or header changes
Use an editor for search and verification. Use DevTools for analysis.
For teams that need a repeatable workflow around bug reports, repro steps, and attached network evidence, this guide to collecting actionable review details pairs well with HAR capture.
How to Read the Network Waterfall
Once the file is imported into Chrome DevTools through the Network tab, the browser reconstructs the session in a readable interface instead of showing a raw dump. A common failure case is opening the HAR in a text editor when the export didn't include content, which leaves response bodies as null strings and removes the most useful debugging detail.
What the Waterfall Is Showing
Each row is one network request. The timeline bar breaks the request into phases. In the HAR spec, each entry includes a timings object with millisecond values for blocked, dns, connect, send, wait, and receive.
That makes the waterfall useful for two different jobs. It can show a broken request, and it can show a slow request that still technically succeeded.
A simple reading model works well:
- Long
waittime often points at server processing or backend delay. - Long
connectordnstime points earlier in the request path. - Long
receivetime can suggest a heavy response body. - A short request with an error status often means the server rejected it quickly.
What to Look for First
Start with the obvious failures. Filter for XHR or Fetch if the issue is tied to a button click, autosave, search, or form submit. Then scan for 4xx and 5xx responses.
After that, compare sequence and dependency:
- Did the request fire at all
- Did it carry the expected method
- Did it return a useful response
- Did another request fail earlier and poison the rest of the flow
A clean waterfall tells a story in order. Missing requests usually matter as much as failed ones.
A practical example: a reviewer says “save doesn't work.” The waterfall may show a POST request returning an auth-related response, followed by no follow-up fetch for refreshed state. That immediately narrows the bug from “save UI is broken” to “request reached the server but auth or session state failed.”
Common Pitfalls When Capturing and Opening
You open the HAR, spot the failing request, click Response, and get nothing useful. That usually means the debugging failure happened during capture, not during analysis.
Empty Bodies Break Real Debugging
A HAR can load cleanly and still be useless. The common case is missing response content. The request list is there, status codes look fine, but the body you need for an API error, redirect response, or validation message was never saved.
That usually happens because the export did not include content, or the browser session captured only summary data. If the response tab shows null, blank content, or a stub with no payload, stop there and ask for a new capture. Digging deeper into that file rarely gets you closer to the fix.
The practical lesson is simple. Opening a HAR is the easy part. Opening one with enough detail to explain the bug is what matters.
Incomplete Logs Hide the Request That Matters
A second failure mode is a HAR that starts too late or ends too early. The visible error may happen after a login redirect, a CSRF token refresh, or a failed preflight request. If the recording only includes the final screen state, the root cause is missing.
A good recapture usually needs three settings and one discipline:
- Enable
Preserve logbefore reproducing the issue - Start recording before the first relevant action, especially for login or redirect flows
- Reproduce the bug once without extra refreshes or retries
- Stop recording after the failure fully appears, not right after the click
Short captures create false leads. A file can look normal at a glance while omitting the one request that poisoned everything after it.
Field note: modal submits, SSO redirects, and checkout flows often fail one request earlier than the UI suggests.
Sanitized Files and Corrupted Files Are Different Problems
Missing detail does not always mean the same thing. A sanitized HAR is still valid JSON, but it may have cookies, auth headers, query params, or response content removed. That protects secrets, which is often the right call. It also makes some classes of bugs hard to reproduce, especially auth and session issues. If your team needs to share a less-redacted capture, use a documented process such as your company policy or a secure privacy review workflow.
Corruption is different. If the file fails to import, opens as malformed JSON, or shows only part of the request list in multiple viewers, the export itself may be broken. In that case, do not troubleshoot the requests yet. Regenerate the HAR.
Use this quick triage:
| symptom | likely cause | next move |
|---|---|---|
| empty response body | exported without content | request a recapture with content included |
| login flow looks incomplete | log was not preserved or capture started too late | recapture with Preserve log enabled and start earlier |
| auth bug cannot be reproduced | sanitization removed cookies or headers | request a less-redacted file through a secure path |
| file will not load anywhere | corruption | regenerate the HAR |
The gap between "I can open this file" and "I can fix the issue" usually lives here. Missing bodies, truncated flows, and over-sanitized headers are what block the hand-off.
Extracting Actionable Data for a Fix
A useful HAR doesn't end at the waterfall. The actual hand-off starts when one request gets tied to one fix.
Move from Slow Request to Exact Failure
Click into the suspicious request and inspect the parts that matter:
- Headers for auth, cookies, content type, and redirect clues
- Payload for malformed JSON, missing fields, or wrong values
- Response for server error messages or unexpected shapes
- Timing for whether the problem is transport, backend wait, or download size
The HAR specification requires each entry to include a timings object with millisecond values for blocked, dns, connect, send, wait, and receive. That breakdown helps separate “server took too long” from “request never got properly established.”
A practical pattern is to pair the visual signal with the low-level detail. A long bar in the waterfall points to the request. The request detail panel explains why it was long or why it failed.
Turn the HAR into a Developer-Ready Hand-Off
A hand-off is actionable when it names the failing request and the expected behavior in one sentence.
Good hand-off:
- failing request:
POST /checkout - observed result: response returns an error payload
- expected result: order confirmation flow should continue
- attached context: reproduction steps and the HAR
Weak hand-off:
- “checkout broken, see attached har”
There's another trade-off here. Sanitization protects secrets, but stripped headers can block auth debugging. Verified guidance notes that sanitized HAR files can remove sensitive headers, and that can prevent teams from reproducing authentication issues. When the bug is auth-related, the reviewer needs a secure path for sharing enough context to debug it without exposing more than necessary.
The best HAR summary fits in a ticket title and points at one request, one failure, and one expected outcome.
That gives a developer, or a coding agent working from the ticket, enough anchored context to resolve the issue instead of starting another capture cycle.
Best Practices for Sharing HAR Files
A HAR file should be treated like sensitive evidence. Zendesk's troubleshooting guidance notes that HAR logs can include full request and response details, cookies, and timing information, which is why they should be captured carefully, often in an incognito session (HAR privacy guidance from Zendesk).
Sending the file alone isn't enough. The reviewer also needs the exact route, what action triggered the issue, what was expected, and what happened instead. Without that context, the recipient has to guess which request matters.
A solid share package includes:
- The trigger step. “Clicked
Saveon settings after changing billing email.” - The expected result. “Banner should confirm update.”
- The actual result. “Spinner stayed visible and form never resolved.”
- The environment. Browser, logged-in state, and whether capture was incognito.
- Any redaction note. Say if cookies, auth headers, or payload fields were removed.
For teams that pass files between PMs, support, and engineering, a lightweight privacy checklist helps. This privacy page is the kind of thing worth keeping near the workflow.
The point isn't to share more files. It's to share enough anchored context that someone can ship the fix without another round of “can you reproduce this again?”
PinDrop helps teams skip the loose screenshot-and-email loop. Reviewers pin feedback directly on the live page, each pin stays anchored to the exact element and route, and coding agents can pick up the full context in the editor to resolve issues faster. If the goal is to go from “fix pin 4” to shipped without losing context, PinDrop is built for that.
