HAR File Viewer

How to Use This Tool

1. Export a HAR capture from your browser’s Network panel.
2. Choose a HAR 1.2 JSON file no larger than 10 MiB.
3. Review request counts, status results and known sizes; treat missing values separately.

Capture the Problem You Need to Investigate

A HAR file records network requests observed during a browser session. It can help explain a failed API call, a large response or requests that repeatedly wait a long time. It is evidence from one capture, not a complete history of the website or a live outage verdict. Capture the action that produced the problem and note the browser, time and relevant connection conditions.

Open your browser’s developer tools and Network panel before reproducing the issue, then export a HAR. Browser menus differ. A sanitized export is a useful starting precaution, but it is not proof that all personal information has been removed. Keep recordings short and avoid unrelated account activity.

Read the Local File Without Replaying Requests

Choose a HAR 1.2 JSON file up to 10 MiB, equal to 10,485,760 bytes. The file contents are parsed in this browser for the summary; they are not uploaded by this tool. A file with a .har extension still needs valid JSON and the expected log.entries structure. An HTML error page renamed .har is not a capture.

The viewer does not fetch the captured addresses, replay API calls or render captured HTML. It also avoids displaying raw authorization headers, cookies and request or response bodies. Displayed addresses omit user information, query strings and fragments. A path can still contain a name, account number or private document identifier, so visible summaries deserve care too.

The file may contain at most 50,000 request entries, and the visible request table uses pages of 100. The observed request span uses available start timestamps and durations. Missing timing records limit that span; it is not the browser’s measured page-load event.

Interpret HTTP Results Without Guessing the Cause

Response statuses in the 400 and 500 ranges identify recorded HTTP errors. A 404 can mean a missing resource, while a 401 can mean the recorded request lacked acceptable authentication. The status alone does not explain why. A value of zero is not an HTTP response code and should not be presented as a successful response or assigned an invented server error.

Redirects and cached responses are not automatically failures. Compare repeated captures and inspect the relevant request in your own developer tools when more detail is necessary. This viewer cannot tell whether a later retry succeeded outside the captured recording or whether another visitor saw the same problem.

Keep Encoded and Decoded Sizes Separate

A response body-size field describes recorded response-body bytes. A content-size field describes resource content after decoding, so the values can differ with compression. Neither field should silently substitute for the other. Missing or negative unknown sizes remain unknown; they must not be added as negative bytes or treated as proof of an empty response.

For three responses with recorded body sizes 100, 200 and -1, the known subtotal is 300 bytes and one response size is unknown. It is not a complete 300-byte transfer total. Headers, protocol framing, caching and capture-specific reporting also limit comparisons with a network adapter’s traffic counter.

Do Not Read a Duration Sum as Page Speed

Two requests can run at the same time. Summing their 400 ms and 600 ms durations produces 1000 ms of request time, but their combined elapsed span can be shorter. That sum is not a measured page-load time, user-perceived responsiveness score or Core Web Vitals result. It also does not isolate the browser’s CPU work.

Local inspection does not anonymize the original file. Keep it securely, review it before sharing and remove it when it is no longer needed. For a separate connection check, use a supported timing test and compare its scope with the captured application request rather than assuming both measure the same thing.

• Run a Separate HTTP Timing Variation Test

What the Result Means

This does not replay requests, fetch URLs or show raw headers and bodies. Display URLs omit user information, query strings and fragments, but paths can still identify people. The original file is not anonymized.

Common Questions