How to sanitize a HAR file before you share it
Short answer: Export the HAR with Chrome's Export HAR (sanitized)…, which leaves out the Cookie, Set-Cookie and Authorization headers. Then check the file for what that export keeps: tokens in URLs, form data, other credential headers and response bodies. You can replace those values by hand in a text editor, or open the file in HARScope and use Clean & save…. It saves a new copy with secret values replaced by REDACTED and leaves your original untouched. No tool catches everything, so skim the result before you send it.
Why a HAR file needs cleaning
A HAR file records everything your browser sent and received while DevTools was recording. That can include session cookies, Authorization headers, API keys, one-time codes in URLs, passwords typed into forms and personal data in server answers. A live session cookie or token can let whoever holds the file act as you on that site until it expires. Support teams ask for HAR files because they show exactly what went wrong. Before you send one, remove what lets someone sign in as you. If you are new to the format, start with what a HAR file is.
Step 1: export the sanitized version in Chrome
In Chrome DevTools, the Network panel's default HAR export is Export HAR (sanitized)…. Google documents it as leaving out sensitive data such as the Cookie, Set-Cookie and Authorization headers. A full export that keeps them exists, but only after you turn on Allow to generate HAR with sensitive data in DevTools settings. Send the sanitized one unless the person asking explains why they need more. Step-by-step instructions for Chrome, Edge, Firefox and Safari are in how to create a HAR file.
The sanitized export is a good start, not a full clean-up. It can still contain:
- tokens, keys and codes in URLs, including redirect targets;
- credential headers with other names, such as
X-Api-Key; - form submissions and JSON request bodies, which may hold passwords;
- response bodies with personal data or fresh tokens.
Step 2, option A: clean it by hand
- Make a copy of the file and open the copy in a text editor.
- Search for words such as
cookie,authorization,token,password,key,sessionand your email address. - Replace each value, not the name, with something like
REDACTED. - Keep the quotes and commas, so the file is still valid JSON.
- Open the edited file in a HAR viewer to make sure it still loads.
- No tool needed.
- You decide about every value.
- Slow on large files.
- Easy to miss a token in a long URL or body.
- One stray character breaks the JSON.
Step 2, option B: Clean & save in HARScope
HARScope is a free Chrome extension that opens HAR files on your own computer. It has no permissions and makes no network requests. The same viewer also runs on the web as the HAR analyzer. Clean & save arrived in version 1.1.0.
- Open the HAR file: drop it on the page, or click Open HAR file….
- Look at the summary bar. It shows Contains secrets: … — clean before sharing with counts per kind, or No cookies or auth headers found.
- Click Clean & save… (or that summary chip). The dialog Clean this HAR before you share it opens.
- Tick what to replace. Each option shows how many values it found. Options with nothing to replace are greyed out.
- Click Save cleaned copy. Your browser saves a new file, and the dialog says Saved … — … values replaced. Your original file is unchanged.
The new file has the original name with .cleaned.har instead of .har. A note in the file's comment field says it was cleaned with HARScope.
The six options
| Option in the dialog | What it replaces | Ticked by default |
|---|---|---|
| Cookies | Values in Cookie and Set-Cookie headers and in the file's cookie lists | Yes |
| Authorization, token and API-key headers | Headers whose names contain words such as auth, authorization, token, key, secret, session, password, signature, csrf or bearer. Also token-shaped values under any other header name | Yes |
| Tokens and keys in URLs | Secret-named parameters in query strings and #fragments, OAuth code and state, passwords in user:password@, ;jsessionid=-style parameters. Covers request URLs, redirect targets, Referer, Location and Origin headers, script initiator URLs and page addresses | Yes |
| Request bodies and WebSocket messages | The whole body of every request (form fields, passwords, JSON) and every WebSocket message | Yes |
| Response bodies | The whole body of every response | No: support often needs to see what the server returned |
| Tokens inside the bodies you keep | In bodies that stay: secret-named JSON fields and form fields, and token shapes such as JWTs and API keys | Yes |
The token shapes HARScope recognises anywhere in a value are JWTs, AWS access key IDs, GitHub tokens, Slack tokens, Stripe secret keys and Google API keys.
A few headers are kept on purpose because they carry what a sign-in or cross-origin investigation needs: the Access-Control-… headers, WWW-Authenticate and Authentication-Info, and the WebSocket handshake keys. In JSON bodies, fields named code or state are left alone, because there they are usually ordinary data.
What sanitizing does not remove
Both Chrome's export and HARScope work by names and patterns. Neither understands what your data means. After cleaning, these can still be in the file:
- Secrets under unusual names. HARScope says it plainly: A secret under an unusual name can slip through — skim the file before you send it.
- Personal data in bodies you keep. Names, email addresses, phone numbers and order details in a response body stay unless you tick Response bodies.
- Ordinary URL parameters. A parameter such as
email=oruser=is not secret-named and stays. - Addresses and timings. Host names, paths, server IP addresses, timings and headers such as
User-Agentstay. They are what makes the file useful for debugging. - Encoded response bodies. When response bodies are kept, bodies stored in base64 are not searched for tokens.
Clean & save writes a new file. The file open in HARScope stays as it was, so Copy as cURL and Copy response still copy the original values, cookies included. Copy report replaces secret-looking URL parameters, but only in the report text.
Chrome, by hand or HARScope
| Chrome sanitized export | By hand | HARScope Clean & save | |
|---|---|---|---|
| Cookie, Set-Cookie, Authorization | Left out | If you find them | Values replaced |
| Other credential headers | Not documented as removed | If you find them | Replaced when the name matches |
| Tokens in URLs | Not documented as removed | If you find them | Replaced when the name or shape matches |
| Request bodies | Not documented as removed | If you find them | Replaced whole, or only their tokens |
| Response bodies | Not documented as removed | If you find them | Optional |
| Original file | Not applicable | Edit a copy | Never changed |
Before you send it
- Record only what support needs, ideally with a test account and without signing in during the recording.
- Export the sanitized version.
- Clean it with HARScope or by hand.
- Open the cleaned file and search it for your email address, your name and the word
token. - Send it only through the support team's own channel, not a public forum.
- If you think a live session was in the file, sign out of that site afterwards.
Questions
Does Chrome's "Export HAR (sanitized)" remove everything sensitive?
No. Google documents it as leaving out sensitive headers such as Cookie, Set-Cookie and Authorization. Tokens in URLs, form data, other credential headers and response bodies can still be in the file.
Does HARScope change my original HAR file?
No. Clean & save writes a new copy with ".cleaned.har" at the end of the name. The file you opened is not changed.
What does HARScope replace secrets with?
The word REDACTED. Cookie, header and parameter names stay, so the person you send the file to can still see what was sent.
Should I remove response bodies?
Only if they hold data you must not share. Support often needs to see what the server answered, so HARScope leaves the Response bodies box unticked by default.
Does HARScope upload the file to clean it?
No. The extension has no permissions and its page cannot make network requests. The web analyzer runs the same code inside a frame that cannot make network requests either.