ALL DEVELOPER TOOLS56
HAR Viewer
HAR Viewer — Read a Network Log Without Uploading It
A HAR carries your cookies, auth headers and login POST body. This one reads it in the tab and can strip those before you send it on.
Nothing is enforced, but the whole file is read as one JavaScript string — Chrome refuses one past about 512 MB — and the parsed document and its request views then sit in tab memory beside it, measured at about 3.4 times the file's size on a 34 MB capture, with a second copy built while a redacted export is written.
About HAR Viewer
A HAR file is what your browser hands you when you right-click the Network panel and save. It is a verbatim recording of a browsing session, and that is exactly the problem: it carries the Cookie header from every request, the Authorization header from every API call, session tokens, API keys in vendor headers, and the body of every POST — including the one from the login form. Uploading that to a hosted viewer so you can read it is handing a stranger a working set of credentials. This page parses the file in your tab instead. You get a request table you can sort by status, size or time and filter by status class, method, resource type or a URL substring, and selecting any row opens its request and response headers, its query string, its request body and a timing breakdown. Everything printed is derived from the file: the totals skip requests whose size the recording marked unknown rather than counting them as zero, and the page says how many those were. The redact control replaces the credential headers by name and by pattern, empties both cookie arrays and removes the request body, then reports exactly how many values it took out. It does not touch URLs, query strings or response bodies, and the page says so rather than calling the result safe.
Questions
Is it safe to send someone my HAR file?
Not as it comes off the Network panel. A HAR records every request verbatim, so it normally contains your Cookie header, any Authorization or Bearer token, CSRF and session headers, vendor API keys, and the body of every POST — the login form included. Anyone who opens it can sign in as you until those credentials expire. The redact control here removes the parts it can name and tells you how many values it took out, which is a large improvement and is not the same as safe: it leaves URLs, query strings and response bodies exactly as recorded. Read the redacted file before you attach it.
Exactly what does the redact control remove?
By name: Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-CSRF-Token and X-XSRF-Token. By pattern: any header whose name contains token, secret, api-key or session, which is what catches X-Api-Key and the hundred vendor spellings around it. It also empties every value in the request and response cookies arrays and replaces the whole request body, form parameters included. The counts on screen are taken from your file, not from a list. What it does not touch: the URL and its query string, so a token in ?access_token= survives, and response bodies, so a JSON login response still holds whatever it returned.
Why do some requests show a dash instead of a size or a time?
Because the recording says the figure is unknown. The HAR format writes -1 for a size or duration it could not measure, which is routine for requests served from cache, requests the browser blocked, and anything an extension interfered with. Printing that as 0 B would understate the page and quietly flatter it, so those cells show a dash instead. The totals follow the same rule: the transferred figure is the sum of the requests that reported a size, and the rail says how many did not, so you can see how much of the recording the number actually covers.
The TYPE column says json but DevTools called it xhr.
Because the two are reading different things. Chrome and Edge write a private _resourceType field into each entry, and where that exists this page uses it verbatim — which is why most rows in a Chrome HAR match the Network panel exactly. Firefox HARs and anything converted from curl have no such field, so the type is read off the response MIME type instead, and a MIME type genuinely cannot tell an XHR from a fetch from a script tag. The fallback is deliberately coarse for that reason: document, stylesheet, script, image, font, media, json, xml, text or other.
Where is the response body?
Not rendered, in this version. The detail panel shows the request headers, the query string, the request body, the response headers and the timing breakdown. Response bodies are left out for two reasons: they are frequently megabytes of base64 or minified bundles, which no amount of scrolling makes readable, and they are the one part of a HAR that redaction here does not reach, so drawing them on screen would put the least protected content in the most prominent place. The bodies are still in your file and still in the export — which is exactly why the page tells you to read the export before sharing it.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.