Instantly redact Bearer tokens, cookies, phone numbers, national IDs, and query secrets before sharing HAR files or logs in GitHub issues or support tickets. 100% client-side.
100% Client-Side Redaction — 0 bytes uploaded to any server.
Redaction runs entirely inside your browser memory. Your sensitive files and logs never touch our backend, making it completely safe to prepare HAR archives before posting to GitHub issues or support tickets.
Geek check: open DevTools → Network tab — 0 bytes of your data uploaded.
When troubleshooting production incidents or filing bug reports on GitHub and Jira, developers frequently attach network logs, cURL dumps, or HAR captures. Unfortunately, raw logs routinely leak critical authentication credentials: OAuth access tokens, session cookies, customer phone numbers, personal email addresses, and server IPs. Once posted to a public repository or shared ticket, leaked Bearer tokens and cookies can give unauthorized actors administrative access to your APIs and customer data. Sanitizing logs beforehand removes credentials while keeping error codes and network timings intact for debugging.
A HAR (HTTP Archive) file is a JSON-formatted recording of an entire browser network session. Beyond URLs and status codes, it captures complete request headers (such asAuthorization: Bearer ... and Cookie), response headers (such asSet-Cookie session tokens), query strings with embedded API keys, and full POST payloads. Because HAR files serialize both plaintext credentials and user responses, sharing an unedited HAR file is effectively handing over active session tokens and PII. Our tool recursively traverses the HAR structure to neutralize sensitive headers and query keys while ensuring the output remains valid, importable JSON.
Yes, but we always recommend a quick visual scan before publishing. This tool scrubs high-risk identifiers — Bearer tokens, cookies, session IDs, phone numbers, national IDs, email usernames, and internal IP addresses. While automated redaction removes standard credentials and PII, your logs might still contain domain-specific business data (such as proprietary order numbers or company names) that you may want to review.
Never. All parsing, regex replacement, and JSON reconstruction happen 100% locally in your browser memory via JavaScript. 0 bytes of your log data or files are uploaded to any server. You can even disconnect your internet or inspect the Network tab in DevTools to verify that no requests leave your machine.
By default, 7 comprehensive rules are active: (1) Authorization Bearer tokens in headers and text; (2) Cookie and Set-Cookie values (preserving keys); (3) 11-digit Chinese mobile phone numbers (with strict boundary checks to avoid false positives on timestamps); (4) 18-digit Chinese Resident IDs (validated with the GB 11643 checksum algorithm); (5) Email addresses (masking usernames); (6) IPv4 and IPv6 addresses; and (7) Sensitive URL query & body parameters (such as token, key, secret, password, and api_key).
Yes. Every redaction rule has an independent toggle switch right below the input area. Toggling any rule immediately recalculates the output in real time so you can inspect the exact results and fine-tune your sanitization.
Files up to tens of megabytes can be processed directly in browser memory. A friendly warning is displayed for files larger than 2MB. For exceptionally large HAR archives (>50MB), we recommend trimming down non-essential entries in Chrome DevTools before export to keep browser memory responsive.