HAR stands for HTTP Archive. It is a JSON recording of every request a browser made while loading a page, with the timing breakdown, headers, sizes and status codes for each one. Every major browser can export one from its network panel.

How do I create a HAR file?

Open developer tools, go to the Network tab, tick "preserve log", reload the page, then right-click the request list and choose "Save all as HAR with content". Chrome, Edge, Firefox and Safari all offer some version of this.

Is my HAR file uploaded anywhere?

No. The file is read and parsed by JavaScript inside your own browser, and this page has no endpoint that could receive it. You can confirm that by opening your network panel while you use the tool, or by disconnecting from the internet first: the analysis still works.

Why does that matter?

Because a HAR records the requests exactly as they happened, including cookie headers, authorization headers and anything in a query string. That regularly means live session tokens. HAR files are worth treating like a password dump, which is why this tool never transmits one.

What should I look for in a waterfall?

Long flat stretches before anything downloads, which usually means blocking or queueing. A single long bar that everything else waits behind. And the shape of the third-party section, which is where tag managers, chat widgets and analytics tend to accumulate quietly.

What is the difference between wait and receive time?

Wait, sometimes labelled TTFB, is the gap between sending the request and the first byte coming back, so it mostly reflects server work. Receive is the time spent downloading the body once it started arriving, so it mostly reflects size and bandwidth. A slow request is a very different problem depending on which one dominates.

Does a HAR file show Core Web Vitals?

No, and that is a real limit of the format. A HAR records network activity, not what the page felt like: there is no LCP, CLS or INP in it. Those are measured in the browser while a person is actually using the page, which is what real user monitoring does.

Is one HAR file enough to diagnose a slow site?

It is a good start and a poor conclusion. A HAR is one session, on one machine, on one connection, at one moment. It is excellent for finding what happened in that session. It cannot tell you how common the problem is, which is the question that decides whether it is worth fixing.

Free performance tool

HAR File Analyzer

Drop in a .har file to see the request waterfall, where the time went, and what is weighing the page down. Your file never leaves the browser.

Choose a HAR file, or drop one here Read in your browser. Nothing is uploaded, and this page has no endpoint that could receive it.

A HAR is one session on one machine. Pulsetic real user monitoring reports the same load timings and Core Web Vitals for every visitor you actually have.

How to read a waterfall

Each bar is one request, positioned by when it started and how long it took. The colours split that time into stages, and which stage dominates tells you what kind of problem you have.

A long grey stretch at the front is blocking or queueing: the browser wanted to make the request but was not allowed to yet, usually because it had already opened as many connections as it will open to that host. Long purple is wait, the time between the request going out and the first byte coming back, which is nearly always the server thinking. Long green is receive, and that is a size problem, not a server one.

The other shape worth spotting is the staircase, where each request appears to start only once the one above it finished. That is a dependency chain: a script that loads a script that fetches data. Chains cost far more than their total size suggests, because none of it can happen in parallel.

Where the weight usually hides

Sort by third party and the answer is often uncomfortable. Tag managers, chat widgets, session recorders, A/B testing snippets and analytics all get added one at a time, each justified on its own, and collectively they can outweigh the site. The breakdown by domain below the waterfall is the fastest way to see how much of your page belongs to somebody else.

Fonts are the other common surprise. They tend to be requested late, because the browser only discovers it needs them after the CSS parses, and they block text from rendering while they download.

What a HAR file cannot tell you

Two things, and both matter. The first is how the page felt. A HAR records network activity, so there is no Largest Contentful Paint in it, no layout shift and no interaction delay. A page can have a tidy waterfall and still feel slow.

The second is how typical the session was. A HAR is a single capture, usually taken on a developer machine on office broadband, quite often with a warm cache. The problem your users have may not reproduce there at all. That is the gap real user monitoring fills: the same timings plus Core Web Vitals, collected from every real visit, so you can tell a genuine pattern from a bad afternoon.

Frequently asked questions

What is a HAR file?

HAR stands for HTTP Archive. It is a JSON recording of every request a browser made while loading a page, with the timing breakdown, headers, sizes and status codes for each one. Every major browser can export one from its network panel.
How do I create a HAR file?

Open developer tools, go to the Network tab, tick "preserve log", reload the page, then right-click the request list and choose "Save all as HAR with content". Chrome, Edge, Firefox and Safari all offer some version of this.
Is my HAR file uploaded anywhere?

No. The file is read and parsed by JavaScript inside your own browser, and this page has no endpoint that could receive it. You can confirm that by opening your network panel while you use the tool, or by disconnecting from the internet first: the analysis still works.
Why does that matter?

Because a HAR records the requests exactly as they happened, including cookie headers, authorization headers and anything in a query string. That regularly means live session tokens. HAR files are worth treating like a password dump, which is why this tool never transmits one.
What should I look for in a waterfall?

Long flat stretches before anything downloads, which usually means blocking or queueing. A single long bar that everything else waits behind. And the shape of the third-party section, which is where tag managers, chat widgets and analytics tend to accumulate quietly.
What is the difference between wait and receive time?

Wait, sometimes labelled TTFB, is the gap between sending the request and the first byte coming back, so it mostly reflects server work. Receive is the time spent downloading the body once it started arriving, so it mostly reflects size and bandwidth. A slow request is a very different problem depending on which one dominates.
Does a HAR file show Core Web Vitals?

No, and that is a real limit of the format. A HAR records network activity, not what the page felt like: there is no LCP, CLS or INP in it. Those are measured in the browser while a person is actually using the page, which is what real user monitoring does.
Is one HAR file enough to diagnose a slow site?

It is a good start and a poor conclusion. A HAR is one session, on one machine, on one connection, at one moment. It is excellent for finding what happened in that session. It cannot tell you how common the problem is, which is the question that decides whether it is worth fixing.

Trusted by teams at companies around the world

See these numbers for every real visitor, not just this one session

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed