HAR File Analyzer

Inspect browser-recorded requests, transfer sizes and timing.

What Is a HAR File Analyzer?

A HAR file analyzer helps you examine a browser’s recorded HTTP requests and responses to investigate website loading and network problems. A HAR (HTTP Archive) file is a JSON-based capture that can contain request URLs, response statuses, headers, sizes, and timing information. Reviewing that evidence can help locate slow requests, errors, and unnecessary transfers. A HAR represents the traffic captured during a particular session, not a complete measurement of every visitor’s experience.

HAR File Analyzer

Inspect browser-recorded requests, transfer sizes and timing.

Review a browser network log

Runs entirely in this browser: your HAR file is not uploaded to WordPress. Reports recorded requests, statuses, durations, known transfer sizes, third-party hosts and slow requests. HAR timing and transfer sizes can be missing or inaccurate; unknown values are never counted as zero.

Rate this tool 5.0 out of 5 from 1 rating

How to Read a HAR File and Investigate Slow Website Requests

A webpage can appear slow for several reasons: a delayed server response, a chain of redirects, a large image, a blocked script, or a request that repeatedly fails. A HAR recording captures network activity so you can examine what happened rather than guessing from the page’s appearance.

Use a HAR file analyzer as a network troubleshooting aid, not as a stand-alone Core Web Vitals test. The recording reflects the browser, connection, cache state, actions, and time window used to capture it. Before opening a file in any online analyzer, check it for sensitive information. Even exports labeled sanitized may retain private details in URLs or request bodies. The sections below explain how to capture useful evidence and interpret the most important fields.

Read Full GuideShow Less

Capture a HAR File in Chrome, Edge, or Firefox

Start by reproducing the exact page visit or interaction that causes the problem.

Open the affected webpage, then open the browser’s developer tools with F12 or the Inspect command.
Select the Network panel and clear existing requests.
Enable Preserve log if the issue involves navigation, a redirect, or multiple pages. Firefox calls the corresponding option Persist Logs.
Choose whether to leave browser caching enabled. For a cold-load investigation, disabling cache can be useful; for a repeat-visit issue, keep it enabled.
Reload the page or reproduce the interaction, then export the captured requests as a .har file. In Chrome and Edge, prefer the sanitized HAR export option.

Chrome and Edge offer HAR export controls in the Network panel. Firefox provides Save All as HAR. Check that recording was active and that the exported file contains the requests needed for your investigation.

Protect Credentials Before You Analyze or Share a HAR

A HAR file can contain secrets. Depending on the export settings and recorded actions, it may include cookies, authorization headers, query-string tokens, form values, response bodies, or personal information.

Browser sanitization reduces particular risks, but it does not guarantee that every private value is removed. Avoid recording payment forms or real account credentials when a test session will reproduce the problem. Inspect and redact the file before sharing it with support teams or uploading it to a third-party service.

The exact privacy and processing behavior of the SEOToolCheckers analyzer must be checked in the installed plugin. Do not assume that an uploaded HAR remains on your device or is immediately deleted unless the implementation confirms it.

Understand the Request and Response Fields

HAR is structured JSON, commonly using the HAR 1.2 format. A recording typically contains a log object with an entries array. Each entry describes one captured HTTP exchange, although the amount of available detail varies by browser and export method.

HAR field	What it describes	Diagnostic use
`request.url`	Address requested by the browser.	Find unexpected domains, query strings, or repeated resources.
`request.method`	HTTP method such as GET or POST.	Distinguish resource fetches from API submissions.
`response.status`	HTTP response status, when recorded.	Investigate errors, redirects, and cache validation.
`response.content`	Content metadata and sometimes a response body.	Review resource type and reported content size.
`startedDateTime`	Timestamp when the entry began.	Place requests in a loading sequence.
`time` / `timings`	Total duration and timing phases.	Separate connection delays from waiting and receiving.

The presence of a field does not guarantee the value is reliable or complete. Some phases are unavailable, some bodies are omitted, and browsers may add nonstandard extensions.

Read the Network Waterfall Instead of Adding Every Duration

A network waterfall places requests against a timeline. If several downloads run at once, their durations overlap. Adding all request times does not equal page load time. Identify which requests begin early, which complete late, and which hold up a dependency or user action.

Compare the first HTML document with CSS, JavaScript, fonts, images, and API calls. An early stylesheet that finishes late can have a different practical impact from a background analytics request that finishes after the page is usable. A waterfall is strongest when paired with render-oriented measurements from browser performance tools.

Decode DNS, Connection, Waiting, and Receiving Time

Timing phases can suggest where a delay occurs, but no individual number proves its cause. The table below reflects common HAR timing terminology.

Phase	Typical meaning	What to investigate
`blocked`	Time waiting before the request could be sent.	Scheduling, connection limits, or queueing.
`dns`	DNS name resolution.	Slow or repeated lookups, where measured.
`connect`	Establishing a network connection.	Connection setup and network conditions.
`ssl`	TLS handshake, often included within connection timing.	Secure-connection setup, where reported.
`send`	Sending the HTTP request.	Large uploads or constrained connections.
`wait`	Waiting for the response after sending the request.	Server work and network latency; not server execution time alone.
`receive`	Receiving the response.	Payload size and transfer conditions.

For example, if one request spends an illustrative 850 ms in wait and 40 ms in receive, investigate response latency before focusing on download size. The waiting phase is related to time to first byte, but their definitions and measurement contexts are not necessarily identical. Do not add ssl to connect indiscriminately because it may be included within it.

Recognize Failed Requests, Redirects, and Cache Responses

Look for patterns rather than treating every unfamiliar status as a fault. A 200 commonly indicates a successful response. 301 and 302 indicate redirects; several consecutive redirects can add unnecessary requests. 404 means the requested resource was not found, while 500 indicates a server-side error.

A 304 Not Modified often means a cached response was successfully revalidated; it is not automatically a broken request. Some browser-initiated failures may have incomplete HTTP status information rather than a normal response. Also inspect Cache-Control, ETag, and transfer information before concluding that a resource was downloaded again.

Separate Transfer Size from Decoded Resource Size

HTML, CSS, JavaScript, and other responses may be compressed in transit. A HAR may report different size concepts such as HTTP response body size, content size, and browser-specific transfer-size fields. These numbers are not interchangeable, and headers can be counted differently across tooling.

If an image or script looks unusually large, confirm its format, dimensions, compression, and actual transfer size. A 1 MB decoded script does not necessarily require a 1 MB network transfer. Conversely, a small transferred script can still execute expensive work after download. Use the Page Weight and Resource Analyzer and browser performance recordings to investigate beyond network size.

Worked Diagnosis of a Slow Product Page

Consider a hypothetical ecommerce product page whose first meaningful content feels delayed. A HAR capture might show the document request waiting 720 ms for a response, three sequential redirects before reaching an external image, and a product API request returning 503. These are illustrative observations, not measurements of this website or a test performed by the tool.

Investigate the document’s long waiting phase using server logs or application monitoring.
Update the image URL to its final destination if the redirects are unnecessary and within your control.
Check the product API failure and whether the page handles unavailable data appropriately.
Capture the page again under comparable cache and network conditions, then compare the same requests.

Fixing the largest number in the file is not always the best next action. Focus on the requests that block essential content or fail a user-critical workflow.

Why a HAR May Not Match Lighthouse or Core Web Vitals

HAR captures network exchanges, not the full rendering pipeline. It generally does not establish Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift by itself. Those metrics depend on rendering, user interaction, and layout behavior in addition to network delivery.

A HAR recorded on a warm desktop cache also cannot stand in for a first visit on a slower mobile connection. For better comparisons, record the browser version, test URL, cache setting, network throttling, authentication state, and actions performed. Use the PageSpeed Insights Checker for a separate performance perspective and treat its results as distinct evidence.

Troubleshoot Empty, Invalid, or Misleading HAR Captures

If an analyzer cannot read the recording, first open the file in a text editor and confirm it is valid JSON with a log object and an entries array. An empty array can mean the browser was not recording when the action occurred. A truncated file can result from an interrupted export or incompatible processing limit.

If requests disappear after navigating, repeat the capture with Preserve log enabled. If a result seems incomplete, check whether the browser filtered the exported requests, the format omits response bodies, or the analyzer supports only part of the data. Large HAR files may require a smaller, focused recording; confirm file limits in the actual interface rather than assuming one.

Bottom line: treat a HAR as a timestamped network record. It becomes useful when you connect particular requests, statuses, sizes, and timing phases to a reproducible user problem, then verify the suspected cause with the appropriate tool.