HAR व्यूअर

Filters and sorts operate on the in-memory entry list. Combine text search with status family and sort mode to isolate the failing or slow subset quickly.

• Failed includes status 0 (aborted / blocked) and any status ≥ 400.
• Text filter is case-insensitive substring matching — paste a path segment, not a full regex.
• Status family counts in the header reflect the full capture, not the filtered subset.

Each row’s colored bar is a proportional breakdown of HAR timings phases. Read the bar left-to-right as the request lifecycle; compare bar length across rows against the session’s max duration.

Phase meanings

• blocked — queued behind other connections or browser limits
• dns — hostname lookup
• connect — TCP handshake
• ssl — TLS negotiation
• send — uploading the request body/headers
• wait (TTFB) — server processing until first response byte
• receive — downloading the response body

How to read it

• Long wait with short receive → server or upstream latency, not payload size
• Long receive → large body, slow network, or uncompressed assets
• Long connect/ssl on many hosts → connection reuse or CDN issues
• Long blocked → too many parallel connections; check HTTP/2 multiplexing
• Missing phases (empty bar segments) → exporter omitted timings; total time may still be present

A checkout page feels sluggish. DevTools shows many requests and you need the one API call that owns the delay — not a guess from the waterfall screenshot.

How HAR Viewer solves it

1. Save HAR with content from the slow interaction only (narrow the recording window).
2. Import into HAR Viewer and sort by slowest.
3. Open the top entries and compare wait vs receive in Timing.
4. Filter to the API host or path once you identify the culprit.
5. Copy cURL and attach timing notes (wait ms, status, URL) to the performance ticket.

You hand backend a reproducible slow call with phase evidence instead of “the page is slow.”

A bug only appears in a real browser session (cookies, redirects, third-party scripts). You need to replay the critical request sequence in Postman, curl, or a staging client.

How HAR Viewer solves it

1. Capture HAR while reproducing the bug once.
2. Filter to the app origin; hide static assets if they clutter the list.
3. Walk entries in order; note 3xx chains and auth headers on the failing call.
4. Copy cURL for the failing request and any prerequisite token/login call.
5. Replay locally, adjusting host to staging if needed.

You recreate the browser network path without keeping DevTools open or re-clicking the UI.

Support escalates a 500 on production. Frontend has a HAR; backend needs a minimal, safe artifact — not a 40 MB dump of every image and analytics beacon.

How HAR Viewer solves it

1. Filter to the failing API path and status family 5xx (or failed).
2. Confirm request method, URL, status, and timing in Overview.
3. Copy cURL after stripping cookies and Authorization (see PII redaction).
4. Paste Raw JSON for only the relevant entries into the ticket, or describe URL + status + wait ms.
5. Link related correlation IDs from response headers when present.

Backend gets a focused, redacted reproduction instead of an unfiltered HAR full of secrets.

HAR files often contain cookies, bearer tokens, emails, account IDs, and POST bodies with PII. The viewer never uploads your file — but chat, email, and ticket systems will if you attach an unredacted capture.

Redact before sharing

1. Search the Raw tab / exported JSON for Authorization, Cookie, Set-Cookie, and token query params.
2. Replace secret header values with REDACTED; keep header names so backend knows auth was present.
3. Strip or truncate request/response bodies that contain emails, phone numbers, or card data.
4. Prefer “HAR without content” when bodies are not required for the bug.
5. Never commit production HARs to git — treat them like logs with credentials.

Still safe locally

Inspection in this tool is in-memory and client-side. Risk starts at the moment you copy, screenshot, or attach the file elsewhere.

Copy cURL rebuilds the selected request with method, URL, headers, and body so you can replay it in a terminal or import into an API client.

• Use cURL after confirming the entry is the failing or slow call — not a prefetch.
• Expect browser-only headers (sec-ch-ua, etc.); remove them if the API rejects unknown headers.
• Rotate any token that appeared in a shared cURL snippet.
• For multipart or binary bodies, verify the exported body still matches what the server expects.

Symptoms: import appears to succeed but the request list is empty, or the tool rejects the file.

Why it happens

The file is not valid HAR JSON, log.entries is missing/empty, or you exported a truncated download.

Diagnose

Open the file in a text editor: confirm a top-level log object with an entries array. Check file size — 0-byte or HTML error pages are common failed downloads.

Fixes

1. Re-export from DevTools: Save all as HAR (with or without content).
2. Ensure the Network panel was recording and not filtered to an empty subset at save time.
3. Validate JSON (trailing commas / single quotes break parsers).
4. If the HAR was emailed, confirm the attachment was not stripped by a security gateway.

Symptoms: total duration shows but the waterfall is a flat bar or missing phase colors.

Why it happens

Some exporters omit per-phase timings or set phases to -1 when unknown. The viewer only paints phases with positive millisecond values.

Diagnose

Open the Timing or Raw tab and inspect entry.timings. Negative or absent keys mean the capture lacks phase detail.

Fixes

1. Re-capture from Chromium DevTools with the Network panel open during the full request.
2. Rely on entry.time and status/URL for triage when phases are absent.
3. Compare multiple entries — if all lack phases, the exporter is the limit, not a single request.

A flat bar still encodes relative total time across the session via bar width.

Treat every HAR as sensitive until proven otherwise.

• Assume cookies and Authorization headers are present in “with content” exports
• Redact before Slack, Zendesk, GitHub, or email attachments
• Prefer scoped captures (one user flow) over full-page dumps
• Do not paste production HARs into public LLM chats
• Delete local copies after the incident is closed if they contain customer data

• Record the smallest window that still reproduces the issue
• Sort by slowest before reading individual timings
• Separate client failures (4xx) from server failures (5xx) with status filters
• Pair waterfall wait spikes with backend traces or APM spans when available
• Export cURL for the failing call and one successful baseline for comparison
• Document URL, status, wait ms, and correlation ID in the ticket title/body