A HAR (HTTP Archive) file is the JSON export of your browser's Network panel:
every request a page made, with its method, URL, status, size, timing breakdown, and full
request and response headers. Export one from DevTools — in Chrome, the Network panel's
Export HAR button; in Firefox, the Network tab's gear menu → Save All As HAR;
in Safari, the Web Inspector Network tab's Export button — drop it here, and you get a
waterfall on a shared timescale, sortable columns, type and status filters, and a detail panel
with headers, query parameters, timing phases, and a copy-as-cURL button.
Here is the part nobody warns you about: do not upload a HAR file to a random site.
Those captured headers include your Cookie header and your
Authorization bearer tokens. A HAR from a logged-in session is, for practical
purposes, a copy of your credentials — enough for whoever holds it to act as you. Nearly every
online HAR viewer works by uploading your file to a server. This one does not: the file is
parsed in your tab with JavaScript, there is no network request, and the cURL export redacts
cookie and auth headers unless you deliberately turn redaction off.
Working on the request rather than the capture? Replay one with the
HTTP Request Builder, audit what came back with the
HTTP Header Analyzer, turn a captured command into
code with the cURL Converter, or poke at a socket with the
WebSocket Tester. If the copied command looks cryptic,
cURL flags explained walks through what each one does.
Frequently asked questions
What is inside a HAR file — and why is uploading one risky?
A HAR (HTTP Archive) file is a JSON log of every request a page made: URLs, methods, status codes, timings, and the full request and response headers. Those headers include your Cookie header, Authorization bearer tokens, API keys, and any credentials posted in a request body. Anyone holding your HAR can often replay your session as you. That is why uploading one to a random online viewer is genuinely dangerous — you are handing over live credentials to an unknown server. This viewer parses the file in your browser with JavaScript; the file is never uploaded, and the Copy as cURL button redacts Cookie and Authorization headers by default.
How do I export a HAR file from Chrome, Firefox, or Safari?
Chrome and Edge: open DevTools, go to the Network panel, reproduce the issue, then click the "Export HAR (sanitized)" download button in the toolbar — or right-click any request and choose Copy > "Save all as HAR (sanitized)". The sanitized export strips cookies and authorization headers; to include them you must first tick Settings > Preferences > Network > "Allow to generate HAR with sensitive data", then pick "Export HAR (with sensitive data)". Firefox: open DevTools, go to the Network tab, then use the settings (gear) menu > "Save All As HAR", or right-click in the request list and choose "Save All As HAR". Safari: enable the Develop menu, choose Develop > Show Web Inspector, select the Network tab, reproduce the issue, and click Export. Prefer the sanitized export whenever you plan to share the file.
What does a timing of -1 mean in the waterfall?
The HAR 1.2 spec says a timing value of -1 means "this timing does not apply to this request". A reused keep-alive connection reports dns, connect, and ssl as -1 because no lookup or handshake happened. Those phases are excluded from the bar and from the total rather than counted as zero, so an entry total is the sum of its non-negative phases: blocked + dns + connect + send + wait + receive.
Why is the TLS segment drawn separately from Connect?
The spec states that when ssl is present its time is also included in connect, for backward compatibility. Adding both together would count the TLS handshake twice and make every HTTPS request look about twice as slow. This viewer draws the Connect segment as connect minus ssl and puts TLS in its own adjacent segment, so the bar length still equals the real round-trip.
Why does the Size column sometimes differ from what DevTools showed?
HAR records several different byte counts. Chrome adds _transferSize, the bytes that actually crossed the wire including response headers; the spec defines bodySize as the received body bytes (-1 when unknown) and content.size as the decoded length, which is larger for compressed responses and non-zero even for a response served from cache. This tool prefers _transferSize, falls back to bodySize, then content.size, and the detail panel names which field the number came from.
Does my HAR file get uploaded anywhere?
No. There is no upload, no server round-trip, and no storage. The file is read with the browser FileReader API and parsed with JavaScript in your tab. You can confirm it by opening your own Network panel while using this page, or by loading the page once and then going offline — it keeps working.
What happens if my HAR has a malformed entry?
One bad entry does not cost you the file. Entries missing a request URL, a response status, or a parseable startedDateTime are skipped and listed in a warnings panel, and everything else still renders. Only a file that is not a HAR at all — invalid JSON, no log object, no entries array — is rejected outright, with a message explaining which check failed.