HAR File Viewer Guide: Read a Network Recording Without Guessing

When a page loads slowly or breaks in a way nobody can reproduce, the most useful evidence is often a recording of everything the browser actually requested: every file, every redirect, every error, and how long each step took. That recording is a HAR file, short for HTTP Archive, and it is produced by the network panel in most browsers. The HAR File Viewer opens that JSON file and presents it as a readable table and timeline, so you can find the slow request, the failed request, or the oversized file without reading raw JSON. It is a reading tool, not a live monitor: it shows what happened during the recorded session, and nothing that happened outside it.

A HAR file is structured, which is why a viewer helps. At the top level it records the browser and the pages visited; under that, each entry is one request, with the request method and address, the request and response headers, the response status, the body size, and a detailed timing breakdown. The timings are the most valuable part. They separate the time spent blocked behind other requests, the time spent resolving the address, connecting, and securing the connection, the time spent waiting for the server to respond, and the time spent downloading the response. A page that feels slow for one reason needs a different fix from a page that feels slow for another, and only the breakdown tells you which. A long wait usually points at the server or the application; a long download usually points at a large file or a slow connection; a long block usually points at too many requests competing at once.

How to read a recording

Start with the summary: how many requests, how much data, and how long the whole page took. Then sort by time, longest first, and look at the top few entries: one huge file or one slow request often explains most of the total. Next, sort by status and look for failures: 404s for missing files, 500s for server errors, and redirect chains where one request bounces through several addresses before arriving. Then look at the timeline view, if the viewer offers one, and find the shape of the load: a waterfall that starts with the document, then styles and scripts, then images, is normal, while a long gap before the first request or a request that starts late and blocks the rest deserves attention. Finally, read the timings of the slowest entries: if waiting dominates, the server is the suspect; if downloading dominates, the file size is the suspect; if blocking dominates, the number of simultaneous requests is the suspect.

Worked example

Take a sample recording, with values clearly labelled as an illustration. The page makes 60 requests totalling 4.8 megabytes in 6.2 seconds. Sorting by time shows one image of 2.4 megabytes taking 3.1 seconds to download, which is exactly half the total data, since 2.4 divided by 4.8 is 0.5, and half the total time. Removing or compressing that one image to 0.3 megabytes would cut the data to 2.7 megabytes, since 4.8 minus 2.4 plus 0.3 is 2.7, a reduction of about 44 percent, since 2.1 divided by 4.8 is roughly 0.44. The same recording shows 8 requests returning 404, which is about 13 percent of requests, since 8 divided by 60 is roughly 0.133, and one script waiting 1.8 seconds for the server before downloading anything, a waiting-dominated entry pointing at server work rather than file size. The reading is therefore threefold, in priority order: fix the oversized image, fix the missing files, and investigate the slow script. Each conclusion comes from a different column of the viewer, which is why reading the whole table beats guessing from the total time alone.

Mistakes to avoid

The most serious mistake is sharing a HAR file without redacting it. HAR files routinely contain cookies, authorisation headers, tokens, and sometimes form data, including passwords if a login was recorded. Never send an unredacted HAR file to support, a forum, or a colleague: strip cookies, authorisation values, and query strings carrying tokens first, or record a fresh session without logging in. The second mistake is recording with the cache disabled or enabled without noting which, since that changes timings dramatically. The third is reading a single recording as proof: network conditions vary, so record twice and compare before concluding. The fourth is blaming the largest file when the timings show a waiting problem, or blaming the server when the timings show a download problem; let the breakdown, not the size alone, assign blame. The fifth is recording a session that includes unrelated tabs or background activity, which pollutes the timeline with requests that have nothing to do with the page under investigation.

Putting it into practice

Record cleanly: open a fresh browser window, open the network panel, reload the page, wait for it to settle, then save the recording. Open it in the viewer, work through the summary, the slowest entries, the failures, and the timeline in that order, and write down the top three findings with their timings before proposing any fix. When you ask for help, share the redacted findings, not the raw file, unless the helper explicitly needs the file and you have redacted it. Keep recordings for pages you care about, so you can compare before and after a fix and prove whether it worked. For related inspection work, the JSON Studio helps you examine structured data files, and the HTTP Status Code Checker helps you understand the status codes you see in the table. The companion guide on Website SEO Audit covers the page-quality side, which pairs naturally with network evidence.

Key points

• A HAR file is a JSON recording of every network request a page made
• Timings show waiting, downloading, and blocking separately, so slow causes can be separated
• Status codes and sizes reveal failed, redirected, and oversized requests at a glance
• HAR files can contain cookies and tokens, so always redact private data before sharing

In short: a HAR recording turns "the page is slow" into named requests with timings. Read the slowest entries, separate waiting from downloading, fix the biggest cause first, and never share the raw file without stripping the private data inside it.