Drop a .har from DevTools and see every cookie, Authorization header, token, JWT and private key it carries — then download a copy with the values replaced, before you hand it to support or paste it into an issue.
Your files never leave your browser — all processing is local.
A HAR file records the cookies and tokens of your logged-in session — whoever gets it can sign in as you. Clear them here before you send it.
Drop a .har file here
.har or .json exported from your browser's DevTools — or click to browse. Read in this tab, nothing uploaded.
Need to check several kinds of files at once? Use Metadata Check
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Find zero-width, bidi and tag characters hiding in text you are about to paste or send.
The same job for Word, Excel and PowerPoint: authors, tracked changes, file paths.
Black out tokens and names in a screenshot before you share it.
Look up what the status codes in your HAR mean.