Is my HAR file uploaded anywhere?

No. The file is read with the browser's FileReader and parsed in JavaScript on your machine. HAR files often contain cookies, auth tokens and request bodies, so keeping them local matters.

HAR (HTTP Archive) is a JSON format that browsers and proxies use to record a full session of HTTP requests and responses, including timing. DevTools can export one for debugging.

What do the timing phases mean?

Each entry has a timings object: blocked (queueing), dns (name lookup), connect (TCP), ssl (handshake), send (uploading the request), wait (server think time / TTFB), and receive (downloading the response).

Why are some timing values -1?

The HAR spec uses -1 to mean a phase was not applicable or not measured. For example a reused keep-alive connection has dns and connect set to -1 because no new connection was opened.

Can it show response bodies?

It shows whatever the HAR includes. If you exported without content the bodies are empty; with content they are stored under each entry's response.content.text and previewed here.

What is the HAR File Viewer?

Free in-browser HAR file viewer. Load an HTTP Archive .har export from your browser DevTools and inspect every request, status, size, timing breakdown (DNS, connect, wait, receive) and headers. Nothing is uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

HAR File Viewer — Gera Tools

Name: HAR File Viewer
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Read HAR files without a server

A HAR (HTTP Archive) file is the JSON your browser’s DevTools produces when you save a Network panel session. It captures every request and response — URLs, methods, status codes, headers, cookies, sizes and millisecond-level timings. This viewer parses that JSON entirely in your browser so you can analyse a performance trace or a bug report without pasting a file that may contain auth tokens into a remote service.

How it works

The tool reads the file with FileReader (or accepts pasted JSON) and runs JSON.parse. A valid HAR has a top-level log.entries array; each entry holds a request, a response, a time (total milliseconds) and a timings object. The viewer sums and displays the timing phases — blocked, dns, connect, ssl, send, wait and receive — which together make up the total. Phases reported as -1 mean “not applicable” (for example a reused connection skips dns and connect). Sizes come from response.content.size and the transfer bodySize. Sorting and filtering happen over the parsed array in memory.

Understanding the timing phases in detail

Each HAR entry’s timings object breaks the total request time into phases that tell a different story about where time was spent:

Phase	What it measures	Common cause of high value
`blocked`	Time spent waiting in the request queue	Too many concurrent connections to the same host, or browser resource limits
`dns`	DNS name resolution	Slow DNS server, uncached domain, or external font/script from a slow resolver
`connect`	TCP connection setup	Geographic distance to server, no connection reuse, high server latency
`ssl`	TLS/SSL handshake	First connection to an HTTPS server; TLS 1.3 is faster than 1.2
`send`	Time to upload the request body	Large POST body or slow upload connection
`wait`	Time to first byte (TTFB) from server	Slow server processing, database queries, or cold-start latency
`receive`	Time to download the response body	Large response, slow connection, or no compression

For most page loads on a fast connection, wait (TTFB) and receive dominate. For API debugging, wait alone is usually the key variable — a high TTFB points at server-side processing time before the response begins streaming.

Common debugging scenarios

Slow page load: Sort by time descending. Look at whether the bottleneck is wait (server is slow) or receive (asset is large). Also check whether many small requests are serialised when they could be parallelised.

Failed authentication: Filter for 401 or 403 responses. Expand the entry and look at the request headers — a missing or expired Authorization header is visible here.

CORS errors: A preflight request (method OPTIONS, status 200 or 204) followed by the actual request failing (status 0 or a network error) is the classic CORS pattern. Check the response headers for Access-Control-Allow-Origin.

Third-party slowdowns: Filter by domain to isolate requests to analytics, ads, or CDN providers. A slow third-party tracker on the critical path can delay page interactivity significantly.

Tips and notes

“Save all as HAR with content” includes response bodies; the plain export does not, which keeps the file smaller but hides payloads.
High wait (TTFB) points at slow server processing; high receive points at a large or slow download; high blocked means the request was queued behind others on the same connection.
HAR files frequently contain Authorization headers and Set-Cookie values — scrub them before sharing a HAR publicly.