HAR File Analyzer
A HAR file (HTTP Archive, .har) is a JSON recording of a browser session — every request a page made and every response it got, with full headers, cookies, query parameters and POST bodies. Drop one here and read it properly: totals and time span, requests by status class and host, the slowest five, then every entry with its headers and payload. Sensitive values — Authorization headers, cookies, tokens, passwords — are masked by default, and you can download a redacted copy that is safe to attach to a support ticket. The file is never uploaded: it is parsed in this page, on your device.
Last updated:
Or drop the file anywhere in this box. Everything below is read from the file itself, on this device. Limit: 50 MB. The file is never uploaded.
Values are hidden for a reason: a HAR file usually holds live session cookies and tokens. Only unmask on a screen nobody else can see, and never screenshot the unmasked view into a ticket.
Requests
No entries match these filters.
Request detail
A HAR file is a recording of your keys — treat it that way
HAR files routinely contain live credentials: session cookies that are still valid, Authorization headers, API tokens riding in URLs, and whatever you typed into forms. Anyone holding the file can often replay your session with it — which is why this page never uploads it, why values are masked until you ask, and why even a redacted export deserves care: redaction replaces the secrets, but the file still maps your application’s endpoints, parameters and traffic shape. Send it through a private channel, not a public forum, and ask the recipient to delete it when the ticket closes. The companion article, before you send that HAR file, walks through what leaks and how to capture one safely; for traffic captured off the wire instead of in the browser, the PCAP Analyzer reads packet captures under the same local-only rule.
What a HAR file records — and what this page reads from it
Browsers and debugging proxies (Chrome and Firefox DevTools, Charles, mitmproxy) export HAR from their network panels: a log object whose entries array holds one object per request — method, URL, request and response headers, cookies, query string, POST data, status, sizes and per-phase timings. Support desks ask for these files because they are the ground truth of “the page was slow” or “the API returned 500”: no screenshots, no recollection, just the recording. This page reads that same structure and presents it the way you actually debug with it — a summary first (how many requests, how much transferred, how long the span, which hosts, which were slowest), then a filterable table, then one entry in full. The full walkthrough of capturing, inspecting and redacting one lives in before you send that HAR file, read what is inside it.
The redacted download is the point of the tool. It keeps the HAR structure intact — same entries, same headers, same timings, so any viewer or support engineer can still open it — and replaces only the values that act as credentials: Authorization, Cookie and Set-Cookie headers, every cookie value, and any header, query or form parameter whose name smells like a token, key, secret, session or password, including secrets nested inside JSON POST bodies. One honest limit: a POST body that is neither JSON nor ordinary form data cannot be parsed safely, so it is carried over unchanged — check such a body yourself before you send the file. The CSV summary is masked no matter what the toggle says, because a spreadsheet is exactly the file that gets forwarded. And where the PCAP Analyzer covers traffic captured on the network, this page covers the browser’s own recording of it — the two views of the same conversation.
Frequently asked questions
Is my HAR file uploaded anywhere?
No. The file is opened and parsed in this page, on your device, and nothing is uploaded, transmitted or stored — analysing a file makes no network request. That is a deliberate design rule, not a convenience: a HAR file is one of the most credential-dense files on your machine, and a tool that asked you to upload one to inspect it would be part of the problem.
What exactly gets masked?
Three things, everywhere they appear — the on-screen detail view, the redacted download and the CSV: the Authorization, Cookie and Set-Cookie headers; every cookie value; and any header, query parameter, form field or JSON body key whose name matches token, key, secret, session, auth, password, passwd, jwt or bearer (case-insensitive). In the redacted file those values become the literal text REDACTED; on screen they show as •••••• until you turn on “Show sensitive values”.
Is a redacted HAR completely safe to share?
Safer, not safe. Redaction removes the values that act as credentials, but the file still shows your hosts, endpoints, parameter names, response shapes and timings — a map of your application that you may not want public. Bodies that are neither JSON nor form data are carried over unredacted. Share the redacted file through the ticket or channel the vendor gave you, not a public post, and ask for it to be deleted afterwards.
Why does the table stop at 500 entries?
Very large captures — long sessions, polling apps, pages with trackers — can hold tens of thousands of requests, and rendering all of them would freeze the page. The table renders the first 500 entries that match your filters and says so; the summary always counts the whole file, and filtering by text, status, method or host is how you narrow a huge capture down to the requests you care about. The redacted download always covers every entry.