HAR File Analyzer

Load a HAR file or paste its JSON to review requests and host summaries. Timings and sizes come from the capture, not a new performance test.

Runs locally in your browser
HAR files can contain URLs, headers, cookies, and response metadata. The file is read and analyzed only in your browser.
HAR JSON input

Supports standard HAR files with log.entries. The tool summarizes the capture and does not replay any request.

Capture summary
Slowest requests
Load a HAR file to see the slowest requests.
Host totals
Load a HAR file to see host-level totals.
Review notes
  • Load a valid HAR file or paste its JSON contents.

Find performance signals in an existing capture

The analyzer does not make any network request. Timing values reflect the HAR export, so use it as a review aid alongside browser performance and backend observability data.

How to use HAR File Analyzer

This page reads a HAR 1.2 export in the browser and turns log.entries into a one-screen summary: how many requests the capture holds, how long they ran, how much they transferred, how many returned 4xx or 5xx, and how many took at least a second. No request is replayed and nothing is uploaded.

Open the file with the picker or paste its JSON, then press Analyze HAR. The two tables below the metrics list the twelve slowest requests and the twelve hosts with the highest total time; the review notes call out the errors and the cases the summary cannot see.

  1. Choose a .har file with the picker or paste the JSON into the input box; the file is read locally.
  2. Press Analyze HAR.
  3. Read the capture summary: request count, summed duration, transfer size, 4xx/5xx and requests of at least one second.
  4. Compare the slowest-requests table with the host totals to see whether one asset or one origin dominates.
  5. Press Copy summary to keep the plain-text version, or Clear to start over.

What the capture summary counts

Reading the numbers

Captured duration is the sum of entry.time over all entries, so it measures serialized request time, not the wall-clock length of the page load: parallel requests overlap in reality but add up here. Slow (≥1 s) counts entries whose recorded time reached 1000 ms, and 4xx / 5xx counts responses with a status of 400 or higher.

Transfer size per entry takes the first usable value among _transferSize, bodySize and content.size. A negative value, such as the -1 that HAR writers use for cached bodies, is ignored, and an entry with no usable size counts as zero.

Reading the slowest and host tables

The slowest table is sorted by recorded time and stops at twelve rows; the host table adds up time, requests, transfer and error counts per hostname and keeps the twelve hosts with the largest total. Missing methods, URLs and statuses are printed as an em dash.

The review notes repeat the two counts as findings and add one informational line when no entry carries cache metadata (a Cache-Control header or a cache object). That line is a property of the export, not a verdict on the site.

Where HAR numbers can mislead

An exported HAR is a snapshot written by the browser's developer tools: bodySize can be -1 for cached responses, timing fields vary between exporters, and a Service Worker or a proxy can hide real network time. Treat the numbers as recorded, not as a fresh measurement.

A slow entry is not automatically a problem: a large download or a long-poll endpoint will always dominate the list. Check the URL and the status before you change anything, and compare against browser performance traces or server-side timings.

Recent tools: