HAR Sanitizer & Redactor

Whenever you report a tricky web bug to a vendor support team, their first request is almost always: "Please open Chrome DevTools, export a .har file of the network tab, and attach it to the ticket." What they rarely warn you is that a raw .har (HTTP Archive) file is a complete plaintext recording of your active session - including your live Cookie headers, Authorization: Bearer JWTs, CSRF tokens, API keys, and POST body passwords. This local HAR file sanitizer scans and redacts every sensitive token in your browser so you can share network logs safely without handing over your account.

Why sharing an unredacted .har file is equivalent to handing over your login

When you click "Save all as HAR with content" in Chrome, Edge, or Firefox DevTools, the browser exports a massive JSON tree recording every HTTP request and response that occurred while the tab was open. Because modern web apps authenticate every request with headers or cookies, that .har file contains live credentials that allow anyone who opens it to impersonate your session immediately:

• Session cookies (Cookie and Set-Cookie headers): Contains session_id, __Host-auth, connect.sid, or SSO cookies that grant full account access without needing your password or 2FA.
• Bearer JWTs and OAuth tokens (Authorization, X-Api-Key): Live access tokens and refresh tokens sent to REST and GraphQL endpoints.
• Sensitive query parameters (?token=..., `?api_key=..., `?code=...' + `): OAuth callback codes, signed S3 URLs, and magic-link tokens sitting right in the request URL.
• POST request and JSON response bodies (postData.text, content.text): Plaintext passwords submitted during a login test, credit card fields, or PII returned by user profile APIs.

Sanitizing a .har network capture step by step

1. Load your .har file: Drag your exported .har (or .json) file into the dropzone - even large 20 MB to 100 MB captures parse directly in browser memory.
2. Review detected sensitive items: Inspect the automatic audit summary showing how many Cookie headers, Authorization tokens, sensitive query parameters, and body secrets were detected across all log.entries.
3. Toggle redaction categories and custom keywords: Keep standard rules enabled (Cookies, Authorization / API Keys, Query Params, JSON Body Secrets), and optionally add custom domain names, email addresses, or internal project strings to scrub.
4. Preview the diff: Check the before-and-after request inspector to verify that HTTP status codes, timings, and URLs remain intact for debugging while secret values are replaced with [REDACTED].
5. Download the sanitized .har file: Click Download Clean HAR to save filename.sanitized.har, ready to attach to your Zendesk, Jira, or GitHub support ticket.

What the sanitization engine scrubs while preserving debug value

Smart key-aware Cookie and Header redaction

If a sanitizer blindly deleted entire headers, support engineers wouldn't know which cookies or auth headers were present on a failing 401 Unauthorized request. Instead of deleting the header row, the sanitizer keeps the header name and cookie keys while replacing each secret value - turning session_id=eyJhbGciOi...; theme=dark into session_id=[REDACTED]; theme=[REDACTED]. That way, engineers can see that session_id was sent without seeing its value.

Deep JSON postData and response body scrubbing

HAR files store request and response payloads as stringified JSON inside request.postData.text and response.content.text. The sanitizer parses nested JSON payloads and recursively scrubs keys matching password, secret, token, access_token, refresh_token, apiKey, client_secret, and authorization, plus regex-matched JWTs (eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+).

Custom string and regex replacement rules

If your company wants to hide an internal staging hostname (internal-api.corp.example) or your personal email address ([email protected]) across the entire capture, adding it to the custom scrub list replaces every occurrence across URLs, headers, and bodies in one pass.

A real example: cleaning a 14.2 MB Chrome DevTools capture for SaaS support

Suppose a billing dashboard throws a 500 Internal Server Error on checkout, and you record dashboard-bug.har (14.2 MB, containing 184 network requests).

1. Drop dashboard-bug.har into the HAR File Sanitizer.
2. The scanner parses all 184 entries in 320 ms and reports:

• 142 Cookie / Set-Cookie headers containing __Secure-next-auth.session-token
• 68 Authorization: Bearer eyJhbG... headers
• 9 X-CSRF-Token headers
• 4 JSON response bodies containing "access_token" and "stripeCustomerSecret"

1. You also add your email [email protected] to the Custom Scrub Words field.
2. Click Sanitize & Download HAR. The exported dashboard-bug.sanitized.har preserves all 184 request timings, status codes (200, 304, 500), stack traces, and response structures so the vendor can fix the bug - with zero live session tokens inside.

Practical tips and limitations

• How to export a HAR in Chrome / Edge: Open DevTools (F12), switch to the Network tab, reproduce the bug, and click the downward arrow icon (Export HAR...) in the top toolbar.
• Keep captures short: Start with a fresh tab or click the Clear network log button in DevTools right before reproducing the issue so your HAR file doesn't include 500 unrelated background requests from earlier in the day.

Privacy and 100% client-side execution

A HAR file contains your live session keys, which means you should never upload an unredacted .har file to a server-based online tool. This HAR sanitizer runs 100% locally inside your browser's JavaScript engine. A code audit confirms zero fetch, XMLHttpRequest, sendBeacon, or WebSocket calls - your network logs never leave your machine.

Checklist of sensitive fields inside the HAR 1.2 JSON specification

An HTTP Archive (.har) file is structured around a root { "log": { "entries": [ ... ] } } array. Inside each entry, credentials can hide in five distinct places:

1. entry.request.headers & entry.response.headers: Specifically Authorization, Proxy-Authorization, Cookie, Set-Cookie, X-Api-Key, X-Auth-Token, and X-CSRF-Token.
2. entry.request.cookies & entry.response.cookies: Parsed cookie object arrays containing { "name": "...", "value": "..." } pairs that duplicate the raw Cookie header and must also be scrubbed!
3. entry.request.queryString & entry.request.url: URL query parameters such as ?access_token=..., ?api_key=..., ?sig=..., or ?code=....
4. entry.request.postData.text & entry.request.postData.params: Form-urlencoded login fields or JSON bodies carrying "password", "client_secret", or "refresh_token".
5. entry.response.content.text: API responses returning newly minted JWTs, session secrets, or private user profile objects.

Related tools

Want to format and explore a specific API response payload from your network log? Paste it into the JSON Formatter & Validator. To decode a Base64 header or inspect the claims inside a JWT token locally, use Encoder / Decoder, or test custom redaction patterns in the Regex Tester. Read our full guide on how to sanitize HAR files and redact tokens online.