Load a HAR capture, run the name-based redaction rules and review the output before sharing it: headers, cookies, query strings, form fields and JSON bodies are covered, response bodies when you tick the box, and anything with no recognizable field name stays as captured.
Runs locally in your browserPaste a HAR capture or drop the .har file: the page reads log.entries, replaces the values that match its rules with [REDACTED] and writes the capture back as indented JSON in the same tab. A test capture with three entries reported 22 replaced values with response bodies left alone and 24 with them included; a compact 3.9 KB capture came back as 6.4 KB because the output is pretty-printed.
The rules work by field name - Authorization, X-Api-Key, Cookie, Set-Cookie, api_key, access_token, refresh_token, id_token, token, password, secret, session, jwt, csrf, signature and their variants - across request headers, cookies, query strings, URL parameters, form fields, JSON bodies, response headers and cookies, redirect URLs and HAR custom fields. Values are also matched by shape: Bearer and Basic credentials and a JWT that starts with eyJ are replaced wherever they appear.
A header, cookie or form field is rewritten when its name matches the rule list, whatever the value looks like. A query parameter is rewritten when its name matches, including a bare token= and the OAuth code= of a redirect; the rest of the URL keeps its order, its other parameters and its #fragment, and the replacement is written literally as [REDACTED] rather than percent-encoded. A Location header that holds a URL follows the same query rules.
JSON bodies are walked key by key, so nested objects and arrays are covered too: in the test capture password, a nested api_key, a bare token and a secret inside an array all came back as [REDACTED], while unrelated values such as an e-mail address and a note stayed readable. HAR custom fields that start with an underscore are walked with the same name rules, so a token stored next to the capture is redacted as well.
Response content is only touched when the checkbox is ticked. When it is, a base64 body is decoded first, redacted and encoded back to base64 with its encoding field intact: an access_token inside a base64 JSON body became [REDACTED] and the body still decoded as valid JSON. A body that carries no match is returned byte-for-byte as captured, including its original base64 line breaks.
Everything else in the capture travels unchanged: entry count, page titles and timings, HTTP statuses, header and body sizes, server IP addresses and start times. Running the output through the tool a second time reports 0 redactions, so an already-sanitized capture can be re-checked without further changes.
The rules match field names and credential shapes, not suspicious-looking values. A secret that appears with no name at all - in a URL path, in a HAR comment field, or as the value of an ordinary field such as note - is left as captured, and so is a response body while its checkbox is unticked. The findings line says how many values were replaced; it never claims the file is anonymous, so the output is worth a second look before it is attached to a ticket.
Empty input, malformed JSON and JSON without a log.entries array each end with a sentence of their own and no download: a truncated document is reported with the line and column where parsing stopped, and a JSON document that is not a HAR capture is named as such instead of producing an empty file. The whole run stays in the browser - the page makes no request with the capture in it.