HAR File Sanitizer

Overview

A HAR file is the browser’s own record of a page load, exported from DevTools. It is the single most useful attachment you can put on a “it works for me” bug report, and it is also one of the most dangerous things you can paste into a public issue tracker. A capture of a logged-in session contains your session cookie, your Authorization header, any OAuth code that happened to be in flight, every form you submitted, and every response body the server sent back.

This tool rewrites the capture so that the structure survives and the secrets do not. You keep the request list, the methods, the status codes, the header names, the timings and the sizes — everything a maintainer needs to reason about your problem — while the values that would compromise your account are replaced with [REDACTED].

How to use

1. In DevTools, open Network, right-click the request list and choose Save all as HAR.
2. Paste the JSON here (or open the file and paste its contents).
3. Read the count of redacted fields, then skim the output.
4. Click Download to save sanitized.har and attach that file instead of the original.

What gets removed

The capture stores the same secret in several places, so the tool has to clear all of them. Missing one is the failure that matters: a file that looks sanitized is worse than a file that obviously is not, because you will attach it without a second thought.

• Headers. Cookie, Set-Cookie, Authorization, and any header whose name contains token, secret, credential, session or api-key. Also Location, because a redirect after an OAuth callback carries the authorization code in the URL.
• Parsed cookie arrays. HAR records cookies twice — once as the raw header line and once as a cookies[] array of name/value pairs. Every value in those arrays is cleared regardless of its name, because cookie names do not tell you what a cookie is for (s, _sess and SID are all session cookies in the wild).
• Request bodies. Both postData.text and the parsed postData.params[] are cleared without looking at field names. A login form’s field might be called pass, otp or cvv, and none of those match a keyword list you would think to write.
• Response bodies. Cleared entirely. This is the single largest source of accidental disclosure — a JSON response from /api/me contains the whole user record.
• Redirect targets and WebSocket frames. response.redirectURL and Chrome’s _webSocketMessages, whose first frame is very often the authentication handshake.
• Server IP address and initiator. serverIPAddress exposes internal addressing; Chrome’s _initiator keeps the full URL of the script that triggered the request, query string included.
• Query parameters. Any parameter whose name looks like a credential — token, api_key, AWSAccessKeyId, signature, code, state, sid, and anything containing key, secret or password. Non-secret parameters such as page and lang are left alone so the URLs stay readable.
• Page titles and referrers. A page title is often just the URL, and a Referer header after an OAuth callback carries the authorization code.

What is deliberately kept

Two categories are left alone even though a blunt keyword filter would catch them, because removing them destroys the reason you shared the file:

• CORS response headers. Access-Control-Allow-Origin and friends contain no secrets, and a CORS bug is one of the most common reasons to share a HAR in the first place. Redacting the answer to the question makes the capture useless.
• Authentication challenges. WWW-Authenticate and Proxy-Authenticate describe which scheme the server wants. That is a hint, not a credential.

What this cannot remove

Name-based redaction has a hard limit, and it is worth knowing where it is before you attach the output to a public issue.

• Secrets in a URL path. /reset/9f3c… and /invite/abc123 are indistinguishable from /users/42 without knowing the route. Path segments are left intact, because removing them would destroy the request list.
• Tokens in custom headers with innocuous names. A header called X-Client-Id that happens to carry a signed value will not match any keyword. Skim your own header names before sharing.
• Personal data in non-secret parameters. An email address in ?email= survives, because email is a field name and not a credential. Whether that matters depends on who you are sending the file to.
• The URLs themselves. Internal hostnames, staging domains and API paths are all preserved, and together they describe your architecture.

The practical rule: this tool makes a capture safe to attach to a vendor ticket or an issue on your own tracker. Treat “safe to publish on the open internet” as a separate judgement that you make by reading the file.

Notes

Values are replaced rather than deleted, so the shape of the JSON is unchanged and any HAR viewer will still open the result. The one exception is content.encoding: when a response body is replaced, the base64 declaration that described the original bytes is removed, because [REDACTED] is not base64 and a strict viewer will fail on it.

The counter reports fields cleared or removed, not secrets found. A capture of a static site with no cookies can legitimately report a high number, because every response body counts.

Input that is not a HAR is rejected rather than passed through. An earlier version of this tool accepted any JSON, processed zero entries, and reported “0 sensitive values redacted” as a success — handing back the original file with a clean bill of health. Telling you something is safe is the entire product here, so the tool now refuses anything without a log.entries array.

If you only want to read a capture rather than share it, use the HAR viewer instead. It masks secrets on screen but never rewrites the file, because nothing leaves your machine either way.