HAR File Viewer

What a HAR file contains

HAR stands for HTTP Archive. It is a JSON-based exchange format for a browser network log: the requests a page made, the responses it received, header metadata, sizes and a timing breakdown. Chrome DevTools documents how to save a sanitized HAR or a HAR with sensitive data in its Network features reference. Firefox provides Save All as HAR and Import HAR in the Network Monitor request list. The field structure follows the HAR 1.2 specification.

This viewer reads log.entries. A malformed entry without both a request and response is skipped rather than guessed. Optional fields may be absent, so an unavailable size, timestamp or phase stays unavailable. The tool never invents a status code or turns an unknown duration into zero.

Reading the overview

The overview separates facts that are known from values that were not recorded. Transfer size uses the browser-specific _transferSize when it is a valid non-negative number. Otherwise it uses headersSize + bodySize only when both values are known. Response content size is not treated as transferred bytes because compression, headers, caching and protocol overhead make those quantities different.

Search is literal and case-insensitive; characters such as [ or .* are not interpreted as regular expressions. Filtering changes the visible request list and exported rows, not the capture totals.

How timings are handled

HAR commonly records blocked, dns, connect, ssl, send, wait and receive in milliseconds. A value of -1 means the phase is unavailable. Values below -1, non-numeric values and non-finite numbers are also treated as unavailable.

ssl is normally a portion of connect, not an extra phase after it. Therefore the fallback duration sums blocked, DNS, connect, send, wait and receive without adding SSL again. When the entry’s reported total differs materially from the available phases, the viewer preserves the reported total and shows a warning instead of silently rewriting the capture. Waterfall geometry is always left-to-right, including on an Arabic page, because elapsed time has a fixed chronological direction.

Privacy and safe handling

A HAR may contain enough information to take over a signed-in session. Chrome specifically distinguishes sanitized exports from exports containing Cookie, Set-Cookie and Authorization data. This viewer masks those headers, proxy authorization, API-key-like headers and all URL query values by default. Revealing a header is an explicit local action. Imported strings are rendered as text, so markup inside a URL or header is not executed.

The viewer does not retain request bodies, response bodies, postData or cookie arrays in its working model. In the multi-step flow it stores a bounded, body-free project in IndexedDB for this browser tab, referenced by an opaque tab marker and expired after two hours. It does not replay requests, contact captured hosts or send the HAR through Livewire. Starting over deletes the saved project.

Exports are summaries, not copies of the original capture. URLs remain query-masked, header values and bodies are omitted, CSV cells are protected against spreadsheet-formula execution, and only the current filtered request rows are included. Even so, review any exported file before sharing it: host names, paths and status patterns can still disclose internal systems.

Practical workflow

1. Prefer the browser’s sanitized HAR export.
2. Reproduce only the failing page flow, then stop recording.
3. Open the capture here and filter by status, host path or content type.
4. Compare long waits with DNS, connection and receive time, while remembering that browser and proxy implementations may omit phases.
5. Share only the sanitized summary needed for diagnosis, never the original capture unless the recipient and transfer channel are trusted.