Search DevTools

Jump to any tool or page

HAR Analyzer

Analyze HTTP Archive (HAR) files to visualize API performance and identify bottlenecks.

Upload HAR File

Drag and drop your HAR file here, or click to browse.
(Open DevTools -> Network -> Export HAR)

Data Transformation

About HAR Analyzer

Load a HAR capture from browser devtools and inspect requests, timings, sizes, and status codes without scrolling a network panel. A HAR is a JSON transcript of a session that records complete request and response headers, so it is far more sensitive than most people assume — the file typically contains live session cookies and Authorization headers verbatim.

Related Data Transformation tools

JSON FormatterImage to JSONPII RedactorSheet to JSONJSON to CSV/XLSX

Frequently asked questions

What sensitive data does a HAR file contain, and how do I share one safely?
Everything the browser sent and received, including Cookie and Authorization headers, bearer tokens, API keys in query strings, and POST bodies with credentials or personal data. Handing a raw HAR to a vendor's support team is effectively handing over a working session — anyone holding it can replay authenticated requests until the tokens expire. Before sharing, strip credential headers and bodies, and treat any token that has appeared in a shared HAR as compromised and worth rotating.
What do the timing phases mean, and what does a long wait indicate?
Each entry breaks down into blocked, dns, connect, ssl, send, wait, and receive. Blocked is time queued in the browser, often against the per-host connection limit. Wait is time-to-first-byte: the request has been sent and the browser is idle until the first response byte arrives, so a high wait points squarely at server-side work — a slow query or an unwarmed cache — not at the network. High receive with low wait is the opposite: the server responded promptly but the payload is large or the link is slow.
Why do blocked or stalled times spike on HTTP/1.1 but not HTTP/2?
HTTP/1.1 browsers open at most six TCP connections per origin, so the seventh concurrent request queues and its blocked time grows with the backlog. This is why sharding assets across subdomains used to help. HTTP/2 multiplexes many streams over one connection, so per-origin queueing largely disappears and blocked collapses — though head-of-line blocking moves down to the TCP layer, where a single lost packet stalls every multiplexed stream until it is retransmitted.
Why do transfer sizes in the HAR not match the actual bytes on the wire?
Several reasons. The bodySize and content.size fields distinguish the compressed transfer size from the decompressed entity size, so a gzipped response shows a large content.size and a much smaller bodySize. Header bytes are counted separately in headersSize, and under HTTP/2 that figure is misleading because HPACK compresses headers across requests, making per-request attribution approximate. Cached responses served from memory or disk often record a transfer size of zero while still reporting full content size.
What gets omitted from a HAR capture that I might expect to see?
Response bodies are optional and devtools frequently drops large ones, so a HAR is not a full traffic archive. Requests made before recording started are absent entirely, which is why a page reload after opening devtools is essential. WebSocket frames are recorded inconsistently across browsers, and requests from service workers or other tabs may not appear. Preflight OPTIONS requests are included but easy to overlook when diagnosing CORS, and they are often exactly where the failure is.