Diagnose failed requests, redirects, and cache evidence
Review recorded status and response-header evidence locally while keeping each diagnostic tied to the supplied capture.
HAR Analyzer
Free, no signup. Drop in a browser network capture to inspect failures, redirects, transfer weight, timings, caching, third parties, and tag evidence. The raw HAR never leaves this tab.
Local cap: 50 MiB and 5,000 entries. Request/response bodies, cookies, sensitive header values, and query values are never included in the report.
Runs entirely in your browser — nothing you paste is uploaded or stored. The HAR and its analyzed contents are not uploaded. Close the tab to discard the imported capture. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
How to use it
- Export a HAR with content from your browser’s Network panel.
- Select the file and analyze it locally.
- Review failed requests, redirects, third parties, resource weight, cache evidence, and detected tag requests.
- Download the sanitized JSON report when you need to share evidence. Never share the original HAR without reviewing it separately.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Request waterfall
Chronological request timing from the HAR. Phase widths come from recorded timing fields; overlapping rows are expected.
Requests by resource type
Third-party domains
Tag and consent vendor evidence
Requests needing review
| # | Status | Type | Host / URL | Transfer | Duration | Cache |
|---|
Rate this tool
Sample report
A typical report groups requests by resource type, lists third-party hosts, and surfaces failed requests, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., and explicit cache missesCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. for review. The values always come from the selected HAR; this sample description is not a benchmark.
How it works
The browser reads the HAR locally, validates its shape and limits, removes sensitive URL and header values, then classifies the bounded request entries. No request or response bodies are included in the displayed or exported report.
What the report can show
- Failed requests and redirect responses.
- Transfer bytes and summed request duration as HAR-recorded evidence, not a page-load score.
- First-party versus third-party hosts based on the first valid request host.
- Cache hit, miss, and revalidation evidence from recorded response status and headers.
- Tag-manager, analytics, advertising, and consent loader/request patterns.
Privacy and interpretation boundaries
HAR files are sensitive source material. Analysis is local, but the original file remains your responsibility. The sanitized export contains redacted URLs and header names only—not header values, bodies, post data, or cookies. Timings can overlap, browser HAR exporters differ, and a network request does not prove a vendor processed it.
Frequently asked questions
Is my HAR uploaded?
No. The selected file is parsed and analyzed by JavaScript in this browser tab. The analyzer does not send or persist the raw HAR or its contents.
Can HAR files contain secrets?
Yes. HAR files can contain cookies, authorization headers, query values, and request bodies. This tool omits bodies, cookies, sensitive headers, and all query values from its results and exports, but you should still protect the original file.
What are the analysis limits?
Files are capped at 50 MiB and analysis at 5,000 entries. If more entries exist, the report clearly states how many were not checked.
Does tag evidence prove tracking fired?
No. A matched request or loader is evidence only. It does not prove data was accepted, attributed, or sent with valid consent.
Feature requests for Har Analyzer
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Inspect request timing and resource weight
Use the chronological waterfall, timing phases, resource types, and transfer totals without treating summed request durations as a page-load score.
Inventory third-party and consent-vendor request evidence
Surface supported loader and request patterns while preserving the boundary between observed network evidence and proof that a vendor processed data or consent was valid.
Filter and hand off a sanitized request review
Search by host or URL, narrow by resource type or third-party status, and export bounded JSON or CSV that omits captured bodies and sensitive values.
Audit sensitive captures without uploading them
Analyze a HAR in an isolated local worker, redact every query value and sensitive header, and discard the imported file by closing the tab.
Watch the full workflow
HAR Analyzer walkthrough
Read the transcript
HAR Analyzer
This beginner walkthrough explains what a H-A-R file is, loads a fictional nine-request recording, and reads the report one section at a time. We will find failures, a redirect, transfer and timing evidence, cache results, third-party requests, vendor patterns, useful filters, and sanitized exports. We will also cover what this report cannot prove and what to check next.
Step 1
H-A-R stands for H-T-T-P Archive. It is a J-S-O-N file that records the network requests a browser made while loading or using a page. This analyzer turns that recording into a local report of failures, redirects, file weight, recorded timing, cache evidence, and outside hosts. It does not visit the website, rerun the requests, upload the file, or save the raw recording.
Step 2
Use it when a page has broken resources, unexpected redirects, heavy requests, questionable cache behavior, or unfamiliar third-party services. You can also filter the request list and give a sanitized report to another team. Every conclusion must stay tied to what this one browser recording captured.
Step 3
Choose a H-A-R one-point-two file exported from browser developer tools. The local limit is fifty mebibytes and five thousand requests; if anything is skipped, the page says so. A raw H-A-R may contain cookies, sign-in tokens, personal details, private U-R-Ls, and submitted form data. The report removes sensitive fields, but you should still protect the original file.
Step 4
First record the browser activity that answers your question. Next, analyze the H-A-R and read the summary, timing waterfall, and request table. Use filters to narrow the evidence, then share a sanitized export if needed. Before sharing the original H-A-R, review it separately because it remains sensitive.
Step 5
Select the fictional shopping-site recording. It contains nine requests and deliberately includes examples of private query values, authorization and cookie headers, body data, a redirect, two failures, cache evidence, and three recognized vendor hosts. The test is designed to prove that those private values do not appear in the report.
Step 6
Select Analyze H-A-R. An isolated browser worker validates the file and reduces every request to the safe fields needed for this report. The status confirms that all nine requests were analyzed. If the file exceeded a limit or had an invalid shape, the tool would show an error instead of a partial success.
Step 7
The summary shows nine requests, two failures, one redirect, and four third-party requests. It also records about two hundred seventy-two kibibytes transferred, six hundred nine milliseconds when request durations are added together, two cache hits, and two cache misses. These numbers describe this fictional recording; they are not a speed score or industry benchmark.
Step 8
The warning cards come directly from recorded evidence: two responses have error status codes, one response is a redirect, and two responses explicitly say the cache missed. A cache miss simply means this request was not served from the supported recorded cache evidence. That may be normal for private or changing content, so investigate before calling it a defect.
Step 9
The waterfall places requests in recorded start-time order. Each colored bar can show time spent blocked, finding the host, connecting, setting up encryption, waiting, and receiving data. Bars can overlap because browsers run requests together. The six-hundred-nine-millisecond total adds each request duration; it is not the page-load time, a Core Web Vital, or a performance grade.
Step 10
The resource list contains four scripts plus one document, stylesheet, image, data request, and other request. The first valid host, shop dot example dot com, becomes the first-party baseline. Four different hosts are labeled third party. Third party only means a different host here; it does not automatically mean advertising, tracking, or unsafe behavior.
Step 12
The review table gathers requests with an unknown or three-hundred-and-higher status, a third-party host, or explicit cache-miss evidence. Our six rows include a redirect, a missing image, a failed data request, and three vendor requests. For each row, you can inspect status, resource type, host, redacted U-R-L, transferred bytes, duration, and cache state.
Step 13
Every query value is replaced with an omitted marker. Inside these U-R-Ls, the marker's brackets appear in their encoded form as percent-five-B and percent-five-D. That covers example tokens, customer values, A-P-I keys, analytics values, and consent values. Sensitive headers are removed, all other header values are discarded, and bodies, post data, and cookies never enter the report.
Step 14
Check Third-party only. The table changes from six review rows to four: the outside A-P-I host, Google Tag Manager, Google Analytics, and OneTrust. The redirect and missing image disappear from this filtered view because they are first party, but they remain in the full report.
Step 15
Search for cookielaw while the third-party filter is active. One OneTrust request remains. Search checks the sanitized host and U-R-L, and the resource-type menu can narrow the same list by document, script, image, data, or another type. These controls change only what you see, not the imported evidence or summary.
Step 16
Download sanitized J-S-O-N when another tool needs the complete structured report. Choose the request C-S-V for a spreadsheet-friendly row list. Both use redacted U-R-Ls and limited fields; they exclude raw bodies, post data, cookies, and header values. The exports are safer handoffs, but they do not make the original H-A-R safe to share.
Step 17
Resource type comes from the recorded content type or U-R-L clues. Cache state comes only from supported response evidence. The first valid request host sets the first-party baseline. To keep large reports usable, the waterfall shows at most sixty timed requests and the review table at most five hundred matching rows.
Step 18
The report can show only what the browser exporter recorded: status, bytes, timing fields, hosts, cache evidence, and supported vendor patterns. Different browsers and capture settings can omit fields. A blank size, missing timing phase, or absent vendor match does not prove that the real event or service was absent.
Step 19
This tool does not rerun requests, prove why an error occurred, measure actual page-load time, verify a cache policy, or prove what a vendor did with data. Sanitization also removes query values that may matter to the investigation. Reproduce important failures, confirm redirect intent, test cache behavior with later requests, and verify vendor activity and consent separately. Keep the original recording protected throughout the handoff.
Use the report to narrow the investigation—not to overstate the recording.
Share the sanitized report when it helps the team, then reproduce important failures, confirm whether redirects are intentional, and test cache behavior again. Verify vendor activity and consent in the systems that can prove them. Keep the original H-A-R protected, because analyzing it locally does not make the source file safe to distribute.
Common issues & how to fix them
- Error One or more requests failed Fix: Reproduce each intended failed request, then repair its URL, availability, or server response so the required resource returns an appropriate success status.
- Warning One or more requests returned a redirect Fix: For unnecessary redirects, update the initiating page or request to use the final URL directly; preserve redirects that are intentional and correctly targeted.
- Information One or more responses contain explicit cache-miss evidence Fix: Confirm each miss is expected for private or uncacheable content; otherwise correct the response or edge-cache policy and verify a later request records a hit.