HAR Files — The HTTP Debug Log You Didn’t Know You Needed

Your API call is failing in production. Works fine in curl, works fine locally. Support opens a ticket and asks you to “share a HAR file.” You nod confidently and Google “what is a HAR file” in a different tab.

This is that tab. Here’s what a HAR file is, what’s inside one, and how to use it to actually find the problem.

What a HAR File Is

HAR stands for HTTP Archive. It’s a JSON file that records every HTTP request your browser made during a session — URLs, methods, status codes, request and response headers, request bodies, response bodies, cookies, and timing breakdowns. All of it, for every request on the page.

The format was standardized by the Web Performance Working Group (spec version 1.2) and is supported by Chrome, Firefox, Safari, and Edge. Think of it as a structured export of your browser’s Network tab — the kind of thing you’d hand to someone debugging your issue without giving them SSH access to your machine.

HAR files are particularly useful when the failure is intermittent, when it only reproduces in a specific browser, or when you need to show a vendor that yes, their API is returning a 500 and it’s not a PEBKAC.

How to Capture a HAR File

Chrome and Edge

1. Open DevTools (F12 или Cmd+Option+I on Mac)
2. Перейдите на Сеть tab
3. Enable Сохранение журнала if the failure happens after a redirect or page reload
4. Reproduce the problem
5. Right-click anywhere in the request list → Сохранить все как HAR с содержимым

Firefox

1. Open DevTools → Сеть tab
2. Reproduce the request
3. Click the gear icon → Save All as HAR

Safari

1. Enable the Develop menu: Safari → Settings → Advanced → Show Develop menu
2. Develop → Show Web Inspector → Network
3. Reproduce the issue
4. Нажмите на Экспорт button (arrow icon in the Network toolbar)

One thing worth noting about Сохранение журнала: without it, the HAR only captures requests made after the current page load. If your failure happens during authentication or inside a redirect chain, you’ll capture an empty or misleading file and spend 20 minutes confused. Enable it before you reproduce the issue.

What’s Inside a HAR File

Every HAR file shares the same top-level structure:

{
  "log": {
    "version": "1.2",
    "creator": { "name": "Chrome", "version": "124.0.6367.82" },
    "entries": [ ... ]
  }
}

The entries array is where all the useful data lives. Each entry is one complete request/response pair. A typical page load produces 50–200 entries; a complex SPA loading a dashboard can push well past that.

Annotated Entry: The Fields That Matter

Here’s a breakdown of the key fields in a single HAR entry:

Поле	Расположение	What it tells you
startedDateTime	Entry	When the request fired, in ISO 8601 UTC. Correlate this with server-side logs to find the exact log line.
time	Entry	Total elapsed milliseconds from request start to response end. The number to sort by when hunting slow requests.
serverIPAddress	Entry	The IP that actually handled this request. Critical behind load balancers — tells you which instance you hit.
request.method	Запрос	GET, POST, PUT, DELETE, etc.
request.url	Запрос	Full URL including query string. Watch for accidentally double-encoded parameters here.
request.headers	Запрос	All request headers. Includes Authorization — auth tokens are in here. This is the privacy concern.
request.postData.text	Запрос	Raw request body. For JSON APIs, this is your payload. If the API is rejecting input, check this first.
response.status	Ответ	HTTP status code. 0 usually means the request was blocked before it could complete.
response.headers	Ответ	Response headers, including Content-Type, Cache-Control, Set-Cookie. Useful for CORS debugging.
response.content.text	Ответ	Response body. For JSON APIs this is the raw JSON. May be base64-encoded for binary responses.
timings.blocked	Timings	Time waiting for a TCP connection slot. High values suggest connection pool exhaustion.
timings.dns	Timings	DNS lookup time. Over ~50ms deserves a look; over 200ms is a problem.
timings.connect	Timings	TCP connection time. High values = network latency or TLS overhead, not server slowness.
timings.wait	Timings	Time from request sent to first byte received (TTFB). This is where slow APIs show up. High TTFB = your server is slow to respond.
timings.receive	Timings	Time to download the response body. High only if the response payload is large.

What to Actually Look For

When you open a HAR you’re usually hunting one of three things:

The request that’s failing

Sort or filter by response.status. In Chrome DevTools you can filter inline with status-code:4xx или status-code:5xx. Once you have the failing request, read the full response.content.text — the error message from the server is usually more useful than the status code.

The request that’s slow

Sort entries by timings.wait (TTFB) descending. High wait = your server is slow. High timings.connect with normal wait = the bottleneck is the network or TLS handshake, not your application. These point to completely different fixes, so getting this right saves a lot of time blaming the wrong layer.

The request that’s missing

Sometimes the bug is a missing request — a webhook that didn’t fire, a preflight OPTIONS that got blocked by CORS, an analytics call that an ad blocker ate. Compare what should be in the HAR against what is. The absence of a request is data.

The Privacy Problem You Should Know About

HAR files contain everything. That includes:

• Authorization headers — Bearer tokens, Basic auth credentials
• Cookie headers — session tokens, JWTs, anything in a cookie
• Request and response bodies — which may contain passwords, PII, or API keys

Chrome does not strip any of this when you export. Before sharing a HAR file with support, a vendor, or a colleague outside your company, remove or redact the sensitive fields.

The fastest way to inspect and clean a HAR before sharing it is the HAR File Formatter — paste your file in, browse the entries, and redact before you send. Alternatively, if you’re comfortable with jq:

# Strip Authorization headers from all entries
jq '.log.entries[].request.headers |= map(select(.name | ascii_downcase != "authorization"))' file.har

Not the prettiest one-liner, but it works.

Reading a Raw HAR File

HAR files are JSON, so technically readable in any text editor. In practice they’re enormous — a typical page load produces a file with hundreds of kilobytes of headers and bodies, all on deeply nested keys. A few ways to navigate them:

• Import into DevTools — Chrome and Firefox both support importing HAR files into the Network tab via the gear icon. This gives you the same filtering and sorting UI as a live capture.
• HAR File Formatter — Browser-based, no install required. Good when you’re sending the file to someone who doesn’t use DevTools.
• jq — For command-line filtering. jq '.log.entries[] | select(.response.status >= 400) | {url: .request.url, status: .response.status}' extracts all failed requests with their URLs in seconds.

For quick analysis and filtering, jq is fastest. For sharing and visual inspection, the browser import or an online formatter means the other person doesn’t need to know what jq is.

Вам также может понравиться