HAR Analyzer
A har analyzer that opens the file in your browser and starts with what is inside it — the bearer tokens, session cookies and API keys a network capture records verbatim — then does the performance analysis.
Free · No signup · The file never leaves your browser
Reads a HAR file and starts with what is in it — the bearer tokens, session cookies and API keys a network capture records verbatim — then does the performance analysis. The file is opened by your browser and never uploaded, which for this format is the whole point.
5 credentials in this file
Every one of these is recorded verbatim and still works. Redact them before this file goes into a ticket, a Slack thread or a vendor upload form — and rotate anything that is not short-lived.
- #1Cookies sent · request header · app.example.com
sid=9f••••••••••••dark (48 chars)
Session cookies are session credentials. Anyone replaying them is logged in as you until the session ends or is revoked.
- #1Session cookie issued · response header · app.example.com
sid=9f••••••••••••cure (54 chars)
A cookie the server set during this recording — often the session that was created when you logged in to reproduce the bug.
- #2Bearer token (JWT) · request header · api.example.com
eyJhbG••••••••••••BsZQ (131 chars)
A JWT in an Authorization header. Anyone with the file can replay it until it expires, and can read every claim inside it without any key at all.
- #3access_token in the query string · URL · api.example.com
at_7c1••••••••••••f1c7 (23 chars)
A credential in a URL is also in the browser history, the Referer header sent to the next site, every proxy log and every server access log on the path.
- #5x-api-key header · request header · api.example.com
ak_liv••••••••••••f3c7 (32 chars)
A custom authentication header. These are rarely short-lived, which makes them worse to leak than a session token.
What the capture shows
- warn1 request failed
Every 4xx, 5xx and aborted request in the capture. If you recorded this to reproduce a bug, start here.
- warn1 text response sent uncompressed
93.9 KB of JSON, JavaScript, CSS or HTML with no content-encoding. Gzip or brotli typically takes text to a fifth of this.
- warn2 requests waited over 500ms for the first byte
Worst was 2020ms. Time-to-first-byte is the server thinking, not the network moving bytes — it is the one number a CDN will not fix.
- warn1 URL fetched more than once
The same GET repeated in one session. Either the response is not cacheable or something is re-fetching it — both are usually accidental.
- info1 of 6 requests went to third parties
76.2 KB from hosts outside your own domain. Each one is a dependency your page load cannot be faster than.
Slowest requests
- 2.21 s
GETwidget.analytics-vendor.io/v1/collect.js · third party2020 ms waiting for the first byte, 4 ms queued, 76.2 KB on the wire, 200 - 840 ms
GETapi.example.com/v2/workspaces/44/items810 ms waiting for the first byte, 1 ms queued, 93.9 KB on the wire, 200 - 310 ms
GETapp.example.com/dashboard260 ms waiting for the first byte, 2 ms queued, 4.8 KB on the wire, 200 - 190 ms
GETapi.example.com/v2/me40 ms waiting for the first byte, 140 ms queued, 620 B on the wire, 200 - 120 ms
GETapp.example.com/dashboard110 ms waiting for the first byte, 2 ms queued, 4.8 KB on the wire, 200 - 95 ms
POSTapi.example.com/v2/items/9812/publish88 ms waiting for the first byte, 1 ms queued, 84 B on the wire, 500
Hosts by bytes
- 94.6 KBapi.example.com3 requests, 1.13 s total
- 76.2 KBwidget.analytics-vendor.io · third party1 request, 2.21 s total
- 9.6 KBapp.example.com2 requests, 430 ms total
The file never leaves your machine — it is read with the browser's own file reader and there is no upload target on this page. That matters more here than anywhere else on this site: a HAR is a complete recording of a signed-in session, and the usual advice is to paste it into whichever analyser comes up first.
Tekk is a spec-driven development platform for people building software with AI coding agents — for the failures that only show up once the pieces are talking to each other.
A HAR file is a credential
The request always arrives the same way. Something is broken, support asks for a HAR, and the instructions are three clicks long: devtools, Network, Save all as HAR with content.
What gets saved is every request and response of that session, headers included. Concretely:
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9…
Cookie: sid=9f3a8c2e1b7d4a6f0c5e8b1a3d7f2c9e
X-API-Key: ak_live_3f8b1c9d7e2a4056b8d1f3c7
GET https://api.example.com/v2/me?**access_token=at_7c1f9b2e4d8a6053f1c7**
All of it still works. The file gets attached to a ticket, forwarded to a vendor, dropped into a Slack channel with forty people in it, and sits in three systems indefinitely.
And nobody reads it, because it is forty thousand lines of JSON and there is no reason to expect anything interesting in it.
So this page leads with that, and does the waterfall second.
What it looks for
| Where | What |
|---|---|
| Request headers | Authorization — bearer tokens, and Basic credentials, which are base64 and recoverable in one step |
Cookie — session cookies are session credentials |
|
X-API-Key, X-Auth-Token, X-Access-Token, Proxy-Authorization and friends |
|
| Response headers | Set-Cookie — often the session created when you signed in to reproduce the bug |
| Query strings | token, access_token, api_key, secret, signature, password and others |
| Bodies and URLs | AWS key IDs, Stripe secret keys, GitHub tokens, Slack tokens, Google API keys, PEM private key blocks, and sign-in POST bodies |
Every value is masked — first few characters, last few, and the length. Enough to find it in the file. Not enough to use.
And it will miss things. A bespoke token in a request body under a name nobody else uses is not recognisable as a token. No findings is not a clean bill of health, and the page says so rather than implying otherwise.
A credential in a URL is worse than one in a header
Query strings get a separate warning because they leak further than people expect. A token in a URL is also in:
- the browser's history
- the
Refererheader sent to the next site you visit - every proxy and load balancer log on the path
- the server's own access log, usually retained far longer than anything else
A header goes to one place. A URL goes everywhere, and the HAR is only the copy you happened to notice.
The performance half
Once the file is safe to share, the rest is the usual work — with the reasoning attached rather than left implied:
- Failed requests first. You recorded this because something broke.
- Uncompressed text. Any JSON, JS, CSS or HTML over ~1.4 KB with no
content-encoding, with the total waste. Compression takes text to about a fifth. Images are excluded — they are already compressed. - Time to first byte over 500ms, separated from DNS, connect, TLS and download. TTFB is the server thinking, and it is the one number a CDN will not fix.
- Queued time. The browser had the request ready and was waiting for a free connection to that host.
- Duplicate GETs. The same URL fetched twice in one session is either uncacheable or accidental.
- Third parties, as a count and a byte total, measured against the registrable domain of the first request.
Why there is no waterfall here
Devtools already draws you one, and it is better than anything a web page can render from a file.
A waterfall is the right shape for finding a pattern across a whole page load. It is the wrong shape when you already know something specific is wrong and want to know which request it was — for that, a sorted list with the numbers written on it is faster to read and easier to paste into a ticket.
How it works
- 1
Open the file, or paste it
The .har is read by your browser's own file reader. There is no upload target on the page, which matters here more than anywhere else: this har analyzer is looking at a complete recording of a signed-in session, and the usual advice is to paste that into whichever site comes up first.
- 2
Read the credentials panel before anything else
Authorization headers, cookies sent and set, custom auth headers, credentials in query strings, and vendor key patterns for AWS, Stripe, GitHub, Slack and Google. Each is shown masked, with the request it came from, so you know what to redact without the page ever displaying the value in full.
- 3
Then look at what the capture shows
Failed requests first, then uncompressed text responses, slow time-to-first-byte, queued requests, redirect chains, URLs fetched more than once, and the third-party split. Every finding says what it means, not just that it happened.
Frequently asked questions
- Do you store or upload my HAR file?
- No. The file is opened with the browser's FileReader and parsed in the page — there is no upload target, no server call, nothing logged and no account. This is not a general privacy statement. A HAR is a verbatim recording of a signed-in session, so uploading one to an unknown har analyzer is handing over working credentials, and most of them do exactly that.
- What is actually in a HAR file?
- Every request and response of a browsing session, including full headers. That means the Authorization header on every API call, every cookie sent and every cookie set, any API key in a query string, the body of every POST, and — if the capture was saved with content — the response bodies too. It is not a summary. It is the traffic.
- Support asked me for a HAR. Is it safe to send?
- Not without reading it first. The request is legitimate and a HAR is genuinely the fastest way to diagnose a network problem, but the file that reproduces your bug also contains the session that was signed in while you reproduced it. Check the credentials panel, redact what it finds, and rotate anything long-lived — an API key in a header does not expire the way a session cookie does.
- How do I create a HAR file?
- In Chrome or Edge: open devtools, go to the Network tab, make sure recording is on, reproduce the problem, then right-click any request and choose "Save all as HAR with content". Firefox and Safari have the same export under different names. If the export is empty, the Network tab was not recording when the page loaded — reload with devtools already open.
- What does it find besides credentials?
- Failed requests, text responses sent without compression and how many bytes that wasted, requests that waited more than half a second for the first byte, requests that sat queued, redirects, the same URL fetched more than once, responses over a megabyte, and how much of the load went to third parties. As a har file analyzer that is the part everyone builds — it is here, it is just second.
- What does time-to-first-byte tell me?
- How long the server spent thinking before sending anything. It is separated out from DNS, connect, TLS and download time because it is the one number a CDN will not fix — everything else is the network moving bytes, and this is your application deciding what to say. A slow TTFB on one endpoint in an otherwise fast capture is usually the answer.
- Why does it flag uncompressed responses?
- Because text compresses to roughly a fifth of its size and the fix is a configuration line. Any JSON, JavaScript, CSS or HTML response over about 1.4 KB with no content-encoding header is listed, with the total wasted across the capture. Images and video are excluded — they are already compressed and gzipping them achieves nothing.
- What counts as a third party?
- Anything not on the registrable domain of the first request. A subdomain of your own site is first party; a CDN or analytics host on its own domain is not. Each third party is a dependency your page cannot load faster than, which is worth seeing as a count and a byte total rather than scattered through a waterfall.
- Can this har file analyzer miss a secret?
- Yes, and it says so on the page rather than claiming otherwise. It knows Authorization headers, cookies, a list of common custom auth headers, credential-shaped query parameters, and the key formats used by AWS, Stripe, GitHub, Slack and Google. A bespoke token in a request body under a name nobody else uses will not be recognised. Absence of findings is not proof the file is clean.
- Are the secrets shown in full?
- No. Every value is masked to the first few and last few characters with the length — enough to find it in the file, not enough to use it. The page has no reason to render a working credential on screen, and neither do you while sharing a window.
- Is there a size limit?
- Captures from a busy page are frequently tens of megabytes. Everything is parsed in the browser, so the practical limit is your machine's memory rather than any cap here. Used as a har file viewer on something that large it stays responsive because response bodies are only scanned for the first 20,000 characters each — which does not miss the headers, where credentials almost always are.
- Does it show a waterfall chart?
- No — as a har file viewer it lists the slowest requests with their timing breakdown instead. A waterfall is the right shape when you are looking for a pattern across a whole page load, and devtools already draws you one. When you have the file open because something specific is wrong, a sorted list with the numbers on it gets you there faster.
- Is a har analyzer different from what devtools already shows me?
- Devtools shows you the session you are in. A har analyzer reads a recording of a session — usually someone else's, from a machine you cannot reach, at a moment that has passed. That is the entire reason the format exists, and it is also why the file needs checking before it travels: the recording keeps working long after the moment did.
- Why is this free, and what is Tekk?
- Tekk is a spec-driven development platform for people building software with AI coding agents. This page costs nothing to run because nothing runs on our servers, so there is no signup wall, no run limit and no upsell inside the tool.
Want a real spec for what you’re building?
Drop a sentence. Tekk grounds it in your actual code and turns it into an executable plan.
Free to try · Connect GitHub during signup