HAR File Analyzer: Inspect Network Requests Without Uploading Them

A HAR (HTTP Archive) file is a JSON document that any browser's DevTools Network tab can export — Chrome, Firefox, Edge, and Safari all support the same “Save all as HAR” action. It captures every request the browser made during a recording session: the URL, method, request and response headers, request and response bodies, and — the part most people are actually after — a per-request timing breakdown split into phases: DNS lookup, TCP connect, TLS handshake, waiting for the first byte, and content download.

The top-level structure is a log object containing an entries array, one entry per request. A single trimmed entry looks like this:

{
  "startedDateTime": "2026-08-03T14:22:07.918Z",
  "time": 842.3,
  "request": {
    "method": "GET",
    "url": "https://api.example.com/v1/orders?page=2",
    "headers": [
      { "name": "Authorization", "value": "Bearer eyJhbGciOiJIUzI1NiIs..." },
      { "name": "Cookie", "value": "session_id=8f2b1c4a...; csrf=91a3c0..." }
    ]
  },
  "response": {
    "status": 200,
    "statusText": "OK",
    "content": {
      "mimeType": "application/json",
      "size": 4821,
      "text": "{\"orders\":[{\"id\":\"ord_291\", \"total\":48.20}, ...]}"
    }
  },
  "timings": {
    "dns": 12.4,
    "connect": 38.1,
    "ssl": 41.7,
    "send": 0.2,
    "wait": 612.8,
    "receive": 137.1
  }
}

That timings object is why HAR files exist at all: wait (time-to-first-byte) dominating an entry points at a slow server or a slow database query on the backend, while a large connect or sslvalue points at network or TLS negotiation overhead that has nothing to do with the application code. People export a HAR file to hand a reproduction of exactly this to someone who can't reproduce the problem on their own machine or network — a teammate debugging a report of “the page is slow for me,” or a vendor's support team asking for evidence that a request is failing.

This is the part that matters more than anything else in this article: a HAR file frequently contains cookies, Authorization headers, bearer tokens, and full response bodies — all in plaintext, all sitting in the request and response header arrays and the content.text fields shown above. Every header the browser sent gets recorded, including the ones carrying your active session.

Sharing a HAR file with a third party is functionally equivalent to sharing your live session. If the file contains a valid session cookie or bearer token, whoever receives it can replay those credentials and act as you — no password, no MFA prompt, nothing else required. This is a genuinely common way session tokens leak: a developer hits a bug, exports a HAR file to attach to a support ticket or a GitHub issue, and ships their own Authorizationheader and session cookie along with it, usually without realizing it's in there at all.

The fix isn't “remember to scrub it manually before you send it” — that's exactly the step that gets skipped under deadline pressure. A tool worth using for this redacts known-sensitive fields (Authorization, Cookie, Set-Cookie, common token and API-key header names) before you export or copy a version to share, rather than leaving detection entirely up to the person under pressure to file the ticket quickly.

To open a HAR file straight from your own browser: open DevTools, go to the Network tab, reproduce the issue while recording, then right-click the request list and choose “Save all as HAR” (Chrome and Edge) or the equivalent export icon (Firefox, Safari). That gives you the .har file to hand off or load elsewhere.

• Re-importing into DevTools. Chrome and Firefox can both load a .harfile back into their own Network panel, which reconstructs the waterfall — useful if you're the one who captured it, less useful if someone sent you a file and you don't want to dig through raw JSON to find one bad request.
• A dedicated HAR viewer.A standalone har file reader renders the waterfall, lets you search across every URL and header in the archive at once, and — critically — doesn't require the person reading it to already have the page loaded in their own browser to compare against.
• Reading the raw JSON directly. Workable for a one-off entry, painful past a few dozen requests — a real page load easily produces a hundred-plus entries, and the timing math (figuring out which request actually blocked the page) is exactly the kind of thing a viewer should do for you rather than something you compute by hand across nested objects.

A network waterfall is the visual form of the entries array: each request is a horizontal bar starting at its own timestamp (startedDateTime) and running for its own duration (time), segmented into the timing phases from the entry above — DNS, connect, TLS, wait, receive. Reading it is mostly about noticing two things.

First, which bars overlap. Requests whose bars overlap in time ran in parallel — the browser's connection pool fetching multiple assets (scripts, images, stylesheets) at once, which is exactly what you want to see for independent resources. Second, which bars only start after a previous bar ends. A chain of requests that each wait for the one before it to finish before starting — request B doesn't begin until request A's bar ends, C doesn't begin until B's does — is a classic cause of a slow page: sequential dependent requests that could have been parallelized, or at least kicked off earlier with a preload hint, instead of discovered one at a time as each response comes back.

The single request with the largest waitsegment sitting early in the waterfall, with a long tail of other requests only starting after it finishes, is usually the actual story behind “this page feels slow” — everything downstream was ready to go and was simply blocked on it.

GenKitLab's HAR Analyzer opens a HAR file and renders the network waterfall, a timing breakdown per request, and a set of findings — the slowest request, the longest sequential chain, requests that failed or redirected — plus a one-click redacted copy that's safe to send, precisely because HAR files leak tokens by default. Everything runs entirely client-side: the file is parsed and rendered in your browser, and nothing you load is uploaded anywhere, which matters doubly here given what a HAR file typically contains.

If the investigation is really about a single response's headers — cache directives, CORS, security headers — rather than the full timing picture across a whole page load, HTTP Header Analyzer is the more direct tool for that narrower question; the HAR analyzer is the right one when the question is about timing, sequencing, or a whole page's worth of requests at once.