HAR File Analyzer

Runs in browser New Web

Open a HAR file exported from the Network tab of Chrome, Edge, Firefox or Safari. The analyzer lists requests that failed or returned 4xx/5xx errors, slow requests with the phase that made them slow (waiting for the server, download, connection, DNS), the largest responses, redirects and redirect chains, identical requests made more than once, uncompressed text responses and http:// requests from an https:// page, grouped by host and resource type. Because a HAR records session cookies, Authorization headers, tokens and form data verbatim, it also lists every secret it finds (values masked) and can write a sanitized copy with them replaced. The file is read in your browser and never uploaded.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

What is a HAR file and is it safe to share?

A HAR (HTTP Archive) file is the JSON log a browser's developer tools export from the Network panel: every request with its URL, method, headers, cookies, timings, sizes and, unless excluded, the response content. It shows exactly what the browser sent and received, which is why support teams ask for one — and why it is sensitive: session cookies, Authorization headers and tokens are recorded in plain text, and a valid session cookie can let someone act as the user. Remove or redact them before a HAR leaves your hands.

How to use HAR File Analyzer

  1. Export the HAR: in the browser's developer tools open the Network tab, tick Preserve log, reproduce the problem, then choose Save all as HAR.
  2. Choose the .har file (or paste its JSON) — it stays in your browser.
  3. Adjust the slow-request and large-response thresholds if the defaults (1,000 ms and 500 KB) do not suit the page.
  4. Press Analyze and read the Checks table first: FAIL rows are errors and secrets, WARN rows are performance findings.
  5. Before sending the HAR to anyone, choose a sanitized copy, run again, review the copy and share that instead of the original.

HAR File Analyzer features

  • Reads HAR 1.2 files exported by Chrome, Edge, Firefox and Safari, up to 30 MB and 20,000 requests
  • Lists requests that got no response (blocked, cancelled, network error) and every 4xx and 5xx response, with the browser's own error text
  • Finds slow requests above your threshold and names the phase that took longest — waiting for the server (TTFB), download, TLS, connection, DNS or queueing
  • Shows the largest responses, redirects and redirect chains, identical requests repeated in the session, uncompressed text responses and http:// requests from an https:// page
  • Groups requests by host (first party or third party) and by resource type, with bytes transferred
  • Lists every cookie, credential header, token and secret-looking parameter in the file with its value masked, and writes a sanitized HAR with those values replaced by [REDACTED], optionally without bodies

HAR File Analyzer example

A shop page that loads slowly and shows an empty "Recommended" block

Input:

Example HAR (invented data for shop.example.com): 9 requests, threshold 1,000 ms / 500 KB, sanitized copy with bodies kept

Output:

FAIL Requests with no response: 1 (analytics.example.org — net::ERR_BLOCKED_BY_CLIENT) · FAIL Server errors: 1 (POST /api/recommendations 503, 2.31 s, waiting (TTFB) 2.30 s) · WARN Client errors: 1 (hero.webp 404) · WARN Slow: 2 · WARN Redirect chain: http://shop.example.com/ → https://shop.example.com/ → https://www.shop.example.com/ · WARN Repeated: GET /api/cart twice · FAIL Secrets: 5 (session cookie, Authorization header, access_token in the URL) · Sanitized copy: 7 values replaced

When to use HAR File Analyzer

  • Reading a HAR a customer attached to a support ticket and finding the failing request in seconds
  • Explaining a slow page with evidence: which request was slow and whether the server or the download was the cause
  • Checking a capture for redirect chains, duplicate API calls and uncompressed assets during performance testing
  • Removing session cookies and tokens from a HAR before attaching it to a bug report or sending it to a vendor

Frequently asked questions about HAR File Analyzer

What is a HAR file?

A HAR (HTTP Archive) file is a JSON log of every request a browser made while the Network tab of its developer tools was recording: URLs, methods, headers, cookies, timings, sizes and, unless you exclude it, the response content. Support teams ask for one because it shows exactly what the browser sent and received.

How do I export a HAR file?

In Chrome or Edge open DevTools (F12), choose the Network tab, tick Preserve log, reproduce the problem, then right-click the request list and choose Save all as HAR (or use the download arrow). In Firefox use the Network tab's gear menu → Save All As HAR; in Safari enable the Develop menu and choose Export in the Network tab.

Is it safe to share a HAR file?

Not as it is. A HAR records session cookies, Authorization headers, access tokens and form fields such as passwords in plain text, and anyone holding a valid session cookie may be able to act as you. Check the "Secrets found" list, create a sanitized copy, review it, and share it only with the people who need it.

What does the sanitized copy remove?

It replaces the values of credential headers (Authorization, Cookie, Set-Cookie, API-key and CSRF headers), all cookies, query, form and JSON fields whose names look secret (token, password, session, key, code…), and JWT and Bearer tokens anywhere in the file with [REDACTED]. Optionally it removes every request and response body. Detection is by name and pattern, so review the copy before sharing it.

Is my HAR file uploaded?

No. The file is read and analyzed in your browser; nothing is sent to Mutqan or anyone else. Copying results needs no account; downloading the report or the sanitized file asks you to sign in to a free account.

Technical notes

Sizes use Chrome's _transferSize when present (bytes over the wire, after compression), otherwise headersSize + bodySize; −1 values in the file mean "unknown" and count as zero. Decoded size is response.content.size. A request with status 0 and an _error field is a request the browser never completed.

Slow-phase attribution reads the timings object: blocked, dns, connect (the TLS time, ssl, is part of connect and shown separately), send, wait (time to first byte) and receive. A long wait points at the server or an upstream dependency; a long receive at the response size or the connection.

Redirect chains are rebuilt from each 3xx response's redirectURL (or Location header) resolved against the request URL. Repeated requests are the same method and URL more than once; some are intentional (polling, retries), so they are reported as WARN, not FAIL.

Secrets are found by header names (Authorization, Cookie, Set-Cookie, X-API-Key, CSRF headers and others), by parameter and JSON field names containing token, secret, password, session, key, code, signature or similar, and by JWT and Bearer patterns anywhere in URLs, headers and bodies.

Limitations and methodology

The analysis is only as complete as the capture: requests made before recording started, or hidden by a filter in the Network tab, are not in the file.

Timings come from the browser that recorded the file and reflect that machine and network at that moment; one capture is a sample, not a benchmark.

Sanitizing is based on names and token patterns. A secret stored under an unusual name, a token inside an HTML page (a hidden form field), a multipart or XML body, or personal data in a response body can survive — remove bodies when in doubt, and always review the copy before sharing it.

First-party hosts are grouped by their last two labels (three for names such as example.com.sa); this is a heuristic, not the Public Suffix List.

Security and privacy

The HAR is read with the browser's File API and analyzed in this page; it is never uploaded, logged or stored by Mutqan.

Secret values are shown masked (first and last two characters and the length), and URLs in the tables and report have secret-looking query values replaced, so copying a table does not copy the secrets.

A HAR you have shared cannot be recalled: if an unsanitized HAR has already been sent, sign out of the affected sessions or rotate the tokens it contained.

References