Log Scrubber: complete usage guide
Redact sensitive values from logs locally before sharing incidents, tickets, pull requests, or vendor debugging snippets.
What this tool does
It scans pasted logs for common sensitive values including emails, IPv4 addresses, JWTs, bearer tokens, key/value secrets, AWS access keys, private key blocks, and URL credentials.
It replaces each match with a clear placeholder so reviewers can understand what was removed without seeing the original secret.
It reports the line and column for every finding, with a masked preview and the replacement token used in the cleaned output.
It keeps all scanning and replacement logic in the browser, so production logs are not uploaded to a third-party scrubber.
Typical use cases
- Prepare production log excerpts for support tickets without exposing customer emails or tokens.
- Clean stack traces and environment dumps before pasting them into pull requests or chat channels.
- Review incident snippets for bearer tokens, JWTs, and database URLs before vendor escalation.
- Create safer reproduction notes from logs that still need enough structure to remain useful.
- Pair with Local Log Parser after redaction to filter cleaned errors and warnings.
Input examples
HTTP log
2026-06-09T18:42:11Z ERROR email=alice@example.com ip=203.0.113.42
Authorization header
Authorization: Bearer sk_live_1234567890abcdef
Database URL
postgres://deploy:supersecret@db.example.com:5432/app
Output examples
Redacted log
email=[EMAIL_REDACTED] ip=[IP_REDACTED]
Redacted header
Authorization: Bearer [TOKEN_REDACTED]
Finding row
Bearer token at 2:16 replaced with Bearer [TOKEN_REDACTED]
Common errors and fixes
Expecting perfect detection for every proprietary secret
Use the findings as a safety layer and still review unusual vendor-specific tokens manually.
Sharing raw findings that contain full secrets
Use the masked preview table and scrubbed output rather than copying original matches.
Disabling too many redaction options
Leave all options enabled unless you have a specific reason to preserve a value type.
Assuming redaction proves logs are safe forever
Treat scrubbed logs as reduced-risk artifacts and keep normal access controls in place.
Parsing logs before removing secrets
Scrub first when the sharing destination is outside the trusted operations boundary.
Security and privacy notes
For the shared privacy terminology, local processing model, external-request labels, and DevTools verification workflow, see the Trust Center.
- The scrubber runs entirely in the browser and does not send log input to a server.
- Masked finding previews avoid re-exposing full secrets in the UI.
- Review scrubbed output before sharing because custom application secrets may need manual removal.
Step-by-step workflow
- Feed Log Scrubber the smallest reproducible sample you can collect from the real issue.
- Review the first findings and separate confirmed signals from assumptions or environment-specific noise.
- Compare a clean baseline sample against the problematic input when you need to isolate regressions.
- Keep one redacted output snapshot with the key findings for tickets, runbooks, or incident handoff.
Quality checklist before sharing output
- Confirm Log Scrubber findings still reproduce with the same input and assumptions.
- Check that the sample includes enough surrounding context to support the conclusion you are drawing.
- Translate notable findings into concrete next checks, ownership, or remediation notes.
- Redact private hosts, tokens, certificates, or customer identifiers before sharing analysis output.
Operational notes
Log Scrubber is most effective when it produces a focused, reproducible evidence bundle that can be handed to the next engineer without extra cleanup.
Frequently asked questions
Does Log Scrubber upload logs?
No. The scan and replacement logic runs locally in the browser.
Can it redact private keys?
Yes, PEM-style private key blocks are replaced when the private key option is enabled.
Does it detect every possible secret format?
No detector can guarantee that. It covers common patterns and should be paired with human review for unusual tokens.
Why are findings masked?
The table is meant to prove what was removed without displaying the full sensitive value again.
Should I use this before Local Log Parser?
Use it first when the same log excerpt will be shared or exported outside a trusted environment.
