# HAR File Sanitizer | Redact Before You Share

Remove passwords, tokens, cookies, API keys, emails and card numbers from a HAR file in your browser, keep JWT claims, and list failed requests for a ticket.

Canonical: https://tamperbox.dev/har-sanitizer

Docs: https://docs.tamperbox.dev/tools/har-sanitizer.md

Updated: 2026-10-26

Reviewed: 2026-10-25

## How it works

The file is read in your browser as JSON and walked request by request. Authorization headers keep their scheme and lose the credential; every cookie value in Cookie and Set-Cookie headers and in the cookie lists is replaced, with the names kept; query parameters, form fields, JSON body fields and headers whose names mean a credential (password, token, secret, key, session and similar) are replaced wherever they appear. Supported header, query, body and comment text is also searched for JSON Web Tokens, private keys, AWS, Google, GitHub, Stripe and Slack key formats, bearer tokens, email addresses and card numbers that pass the Luhn check. Each distinct value gets one placeholder for the whole file, so the same session or user can still be followed from request to request. A JSON Web Token keeps its header and claims, with matching sensitive fields and email claims replaced, and loses its signature, so it can still be read but no longer used. Text bodies stored as Base64 are decoded, cleaned and encoded again. The requests are listed with status and time, and the failed ones can be copied as a Markdown table for a ticket.

The full method, every rule and worked examples are on [docs.tamperbox.dev](https://docs.tamperbox.dev/tools/har-sanitizer/).

## Limits and interpretation

Replacement is by field name and known patterns. Names, postal addresses, phone numbers and other personal details in free text are not detected, so read the file before sharing it. Binary bodies such as images and fonts are kept as they are. Bodies that were changed are written out again, so Content-Length headers may no longer match. IPv4 addresses are kept unless you choose to replace them, because they are usually needed to diagnose network problems. URL-encoded and multipart form fields are inspected. Malformed JSON or multipart bodies are replaced as a whole; data deeper than 100 levels is refused. XML and arbitrary free text receive pattern matching only. Existing placeholder-looking credentials are replaced again. Files are limited to 50 MiB. Nothing is stored.

## Frequently asked questions

### Is a HAR file safe to send to support?

Not as exported. A HAR file records every header, cookie and body the browser sent and received, including session cookies and tokens that let anyone holding the file act as you until they expire. Sanitize it, read it, and sign out of the session you recorded once the ticket is resolved.

### Why are the replacements numbered instead of all being the same?

So the file stays useful. If the same session cookie appears in twenty requests it becomes the same [COOKIE_1] in all of them, and a different session becomes [COOKIE_2], which shows support whether two requests belonged to the same session without revealing it.

### Can support still read my JSON Web Tokens?

Yes, by default. The header and claims such as expiry, issuer and audience stay readable, with email claims replaced, and the signature is removed so the token cannot be used. Choose "Replace the whole token" if the claims themselves are sensitive.

## References

[W3C: HTTP Archive (HAR) format](https://w3c.github.io/web-performance/specs/HAR/Overview.html) · [RFC 7519: JSON Web Token](https://www.rfc-editor.org/rfc/rfc7519) · [RFC 6265: HTTP State Management Mechanism (cookies)](https://www.rfc-editor.org/rfc/rfc6265) · [OWASP: Logging Cheat Sheet, data to exclude](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html#data-to-exclude).