# HAR File Sanitizer > A HAR file carries your session cookies, tokens and passwords. See every one, then download a copy with the values replaced by [REDACTED]. Nothing uploaded. - URL: https://bytescope.dev/en/har-sanitizer/ - Locale: en · Also: [ja](https://bytescope.dev/ja/har-sanitizer.md) · [zh-Hant](https://bytescope.dev/zh-Hant/har-sanitizer.md) - Runs: Your files never leave your browser — all processing is local. - Requires: Any modern browser (Chrome, Edge, Firefox, Safari), desktop and mobile. - Updated: 2026-09-08 ## What it does When support asks you to “export a HAR and send it over”, the file you export is a full recording of every request your browser made: URLs, headers, cookies, request and response bodies. That includes the session cookie that keeps you logged in, the `Authorization` header your app sends on every call, and whatever tokens came back in a login response. Anyone holding that file can often act as you until those values expire. As publicly reported, the 2023 Okta support-system incident involved session tokens taken from HAR files customers had uploaded to a support case — the file did exactly what it was built to do. This page opens a `.har` of up to 200 MiB in your browser, lists what it finds, and builds a copy with those values replaced. Nothing is uploaded; there is no server behind the page. ### What is found Cookies on the request (`Cookie` header and the `cookies` array) and on the response (`Set-Cookie`), with `HttpOnly` or `Secure` ones flagged as likely session cookies. `Authorization` and `Proxy-Authorization` headers: Bearer, Basic — which is a reversible username and password, not a hash — and Digest. `user:pass@` embedded in URLs. Known token headers such as `x-api-key`, `x-csrf-token`, `x-amz-security-token` and `x-goog-api-key`. Secret-looking parameters in request URLs, in redirects and in `Location` and `Referer` headers — `token`, `access_token`, `id_token`, `code`, `state`, `signature`, `X-Amz-Signature`, `password` and the like, including `#access_token` in a fragment. Passwords and tokens in form and JSON bodies, including OAuth token responses with `access_token` and `refresh_token`. JWTs anywhere in the file, shown with their `alg`, `iss`, `sub` and expiry — the signature is not verified. Private keys (`-----BEGIN … PRIVATE KEY-----`). Possible personal data in response bodies: email addresses, E.164 phone numbers, card numbers that pass the Luhn check, Taiwan national IDs with a valid check digit. And internal hosts: `localhost`, `127/8`, `10/8`, `172.16/12`, `192.168/16` and `file://` URLs, which tell a stranger what your network looks like. ### What the redacted copy changes Every finding you leave selected has its value replaced with `[REDACTED]`; the name stays, so support can still see that a `Cookie` header or an `access_token` field was there. Internal host names become `redacted.invalid`, and the recorded header and body sizes of an edited request or response are set to `-1` (unknown), because the old numbers would no longer match the edited content. The copy is scanned again before it is offered, and the page shows the count before and after — if something it knows how to find is still there, you see it. Personal data is listed but not selected by default: removing the email address from a response body can hide the very bug the vendor needs to see, so that choice is yours per finding. When a file contains no cookie and no `Authorization` header at all, the page says so — Chrome DevTools can export a HAR with or without sensitive data, and that looks like one exported without. ### What it cannot do It finds known shapes. A token your app sends in a body field called `x`, or in a format nothing here recognises, can be missed, which is why the report never says the file is safe — it says what was cleared and what you kept. Personal-data matches are marked as “possibly” and are incomplete; they are not a substitute for reading the file yourself before you share it. Redacted requests cannot be replayed, which is the point. Responses stored as base64 binary — images, fonts, downloads — are not scanned. And the page is just as useful the other way round: open a HAR someone sent you to see what they handed over before you forward it. ## Limits Does not verify JWT signatures, replay requests or draw a timing waterfall, and does not scan base64 binary responses (images, fonts). It finds known shapes only — a custom token format can be missed — and it never says a HAR is safe: it lists what was replaced and what you kept. ## FAQ ### Is it safe to share a HAR file? Not as exported. A HAR records headers and cookies for every request, so a file from a logged-in session carries the cookie or token that session runs on, and whoever has the file can often reuse it until it expires. Open the file here first: the page lists every cookie, `Authorization` header, token, JWT, private key and internal host it can identify, and you download a copy with those values replaced. The copy is not declared safe — the report tells you what was cleared and what you chose to keep, and the final read is yours. ### Is my HAR file uploaded anywhere? No. The file is opened with the File API, parsed in this tab, and the redacted copy is a download your browser builds from memory. There is no API behind this page, so there is nowhere for the file to go — which matters for exactly the file you would not want on a server: the one with your live session in it. ### What exactly does a HAR file contain that is sensitive? Everything the browser sent and received for the pages you recorded: the `Cookie` header on each request and `Set-Cookie` on each response, `Authorization` and `Proxy-Authorization` headers, custom token headers such as `x-api-key`, tokens in URLs and in redirect `Location` headers (OAuth often passes `code`, `state` or even `#access_token` that way), passwords in login form bodies, token responses in JSON, and sometimes a private key or personal data in a response body. Request URLs also show which internal hosts your network has — `localhost`, `10.x`, `192.168.x`, a `file://` path — and that is a map someone else should not have. ### Can I remove just the cookies and keep everything else? Yes. Every finding is a checkbox. Everything except possible personal data is selected to begin with; untick anything you want to keep, for instance a public API key support needs to reproduce the problem. Values are replaced by `[REDACTED]` and the names are kept, so the structure of each request is still readable. The copy is rescanned before download, and the before and after counts are shown side by side. ### Why are email addresses and phone numbers not cleared by default? Because a support ticket is usually about the data. If the bug is that a profile page shows the wrong email address, a HAR with the email replaced by `[REDACTED]` hides the one thing the engineer needs to see. Personal data in response bodies — email, E.164 phone numbers, card numbers that pass Luhn, Taiwan national IDs with a valid check digit — is therefore listed as “possibly personal data” and left for you to select. The detection is incomplete by design: it does not know a name or an address when it sees one. ### It found a JWT — what does the alg, iss and expiry mean, and is the token still usable? A JWT is three base64 parts: header, claims, signature. The page decodes the first two and shows the algorithm (`alg`), the issuer (`iss`), the subject (`sub`) and the expiry, so you can tell whether the token in the file is a live one or expired weeks ago. It does not verify the signature — it has no key to verify it with — so it cannot tell you whether the token would be accepted. Treat any JWT with an expiry in the future as usable by whoever holds the file. ### Will support still be able to use the redacted HAR? For reading, yes: the URLs, the sequence of requests, status codes, timings, the names of every header and field, and all the non-sensitive bodies are unchanged. For replaying a request, no — the credentials are gone, which is the point of handing over a redacted file. If an engineer needs to reproduce a call, they should do it with their own credentials, not yours. ### The scan found nothing — does that mean the file was clean? It means nothing of the shapes this page knows how to find was there. When a HAR has no cookie and no `Authorization` header at all, the page notes that it looks like one exported with sensitive data left out, which Chrome DevTools can do. A token in an unusual header, a password in a field with an unexpected name, or a secret in a binary response is not something it can see. Read the bodies yourself before you share a file that matters. ## Related tools - [Invisible Character Checker](https://bytescope.dev/en/invisible-characters.md) — Find zero-width, bidi and tag characters hiding in text you are about to paste or send. - [Office Document Inspector](https://bytescope.dev/en/office-inspector.md) — The same job for Word, Excel and PowerPoint: authors, tracked changes, file paths. - [Redact Screenshot](https://bytescope.dev/en/redact-screenshot.md) — Black out tokens and names in a screenshot before you share it. - [HTTP Status Code Reference](https://bytescope.dev/en/http-status.md) — Look up what the status codes in your HAR mean.