HAR File Viewer & Analyzer

What Is a HAR File?

HAR stands for HTTP Archive. It is a JSON file that records the network activity of a browser tab: every request the page made, what came back, and how long each step took. The format was written up as a draft specification, and version 1.2 is what Chrome, Edge, Firefox and Safari export today, along with proxies such as Charles and Fiddler.

Inside the log object you will find:

• pages: one record per page load with its DOMContentLoaded and load times.
• entries: one record per request, with the method, URL, HTTP version, headers, cookies, query string and any posted data.
• response: status code, headers, cookies set, MIME type, sizes and often the body itself (binary bodies are stored as base64).
• timings: how long the request spent blocked, on DNS, connecting, on TLS, sending, waiting and receiving.
• Browser extras: fields that start with an underscore, such as Chrome's _resourceType and _transferSize, which this viewer uses when they are present.

How to Generate a HAR File in Chrome, Edge, Firefox and Safari

The routine is the same everywhere: open the developer tools, keep the log across page loads, reproduce the problem, then export.

Chrome and Edge sanitize by default. Recent versions leave cookies and Authorization headers out of the exported file. If whoever is debugging needs them (for a login or session bug, say), open DevTools Settings, go to Preferences, find the Network section and turn on Allow to generate HAR with sensitive data. The export menu then offers a version with sensitive data. Only send that file to someone you trust, and sanitize what they do not need.

How to Read the Waterfall and Timings

Each bar in the waterfall starts when the request started and is as long as the request took, on one shared timeline that begins with the first request in the file. The blue line marks DOMContentLoaded (the HTML is parsed) and the red line marks load (images, styles and scripts are done). The colored segments inside a bar are the timing phases:

• Blocked: time spent in the queue before the request could leave. Long blocked times usually mean too many requests to one host at once (browsers open about six connections per host over HTTP/1.1) or a lower-priority request waiting its turn.
• DNS: looking up the server's IP address. Only the first request to a host pays it.
• Connect and SSL: opening the TCP connection and negotiating TLS. In a HAR file the SSL time is counted inside Connect, so the viewer draws them as separate segments without double counting.
• Send: uploading the request. Near zero unless you are posting a large body.
• Wait (TTFB): time to first byte, from the end of sending to the first byte of the response. This is server think time plus one network round trip. A long wait on an API call points at the backend, not the browser.
• Receive: downloading the response. Long receive times mean a big payload or a slow connection.

Patterns worth spotting: a staircase of requests that each wait for the previous one (a dependency chain you may be able to parallelize), a gap with no network activity (JavaScript busy before the next fetch), and one slow request that everything after it depends on. Sort by Time to find the slowest calls, or click the Slowest tile.

HAR Files and Security

A HAR file is a full copy of what your browser sent and received, and that includes the keys to your account:

• Session cookies: anyone holding them can often act as you until the session expires, no password needed.
• Bearer tokens and API keys: in Authorization headers, custom headers like X-API-Key, and query strings.
• Form data: whatever you typed into a form while recording, including passwords on a login page.
• Personal data: names, emails, addresses and order details inside response bodies.

This is not theoretical. In October 2023, attackers who got into Okta's support case system took session tokens from HAR files that customers had uploaded with their tickets. Before you share a HAR: record only the steps you need, use a test account if you can, run it through Sanitize above, send it through the support portal rather than a public channel, and log out afterwards so any session that slipped through stops working.

Using HAR Files in Bug Reports

A HAR shows what the network did. On its own it does not show what the user saw, so pair it with context:

• A screenshot or screen recording of the error message or broken state, so the engineer knows which request matters.
• The exact time and time zone you reproduced it, so the backend team can find the same moment in server logs.
• The steps you took while recording, in order.
• The failing request: turn on Errors only, note the URL, status and any request ID header from the response, and quote the error body.
• Browser and version, plus whether it also fails in a private window.

Copy as cURL turns a request into a command a developer can rerun from a terminal. It copies the original headers, tokens included, so trim those before you paste it anywhere shared.