How to Sanitize Logs Before Sharing Them
Redaction is worth doing, and it is worth being precise about what it achieves. Removing a key from the copy you are about to share protects that copy. It does nothing about the copy already in your terminal, your shell history, or anyone else’s screen.
The short answer
Take the smallest excerpt that shows the problem, run it through automated detection to catch the obvious credentials, then read what is left yourself — the automated pass cannot recognise your internal hostnames, your customer identifiers, or a vendor key format it has never seen.
Redaction edits text. It does not rotate, revoke, or invalidate anything. If a credential has already been pasted somewhere — a ticket, a chat, a screenshot, a commit — treat it as compromised and rotate it at the provider. Cleaning a later copy does not undo the first one.
What automated detection actually catches
This is measured against our own detector, and the second half of the table matters more than the first. A reader who assumes full coverage will share a live credential.
| Kind | Example | Detected |
|---|---|---|
| Email address | [email protected] | Yes |
| IPv4 address | 192.168.1.44 | Yes |
| JWT | eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIn0.abc | Yes |
| Bearer token in a header | Authorization: Bearer … | Yes |
| Credential-style key names | "api_key", "token", "secret", "password" | Yes |
| IPv6 address | 2001:0db8:85a3::8a2e | No |
| AWS access key ID | AKIA… | No |
| GitHub / Stripe / OpenAI / Slack keys | ghp_…, sk_live_…, xoxb-… | No |
| Private key blocks | -----BEGIN RSA PRIVATE KEY----- | No |
| Connection strings | postgres://user:pw@host/db | No |
| Credit card / phone numbers | 4111 1111 1111 1111 | No |
| Cookies and Basic auth | Cookie: session=… | No |
5 kinds are detected and 7 are not. The undetected ones are not oversights so much as a boundary: pattern matching finds shapes it has been taught, and vendor key formats change constantly.
Why “something was found” is not the same as safe
The clearest illustration is a database connection string:
postgres://user:[email protected]:5432/appMeasured: the detector flags this as an email address, because user:[email protected] has that shape. The password inside it is not recognised as a credential. Automated detection found something here — just not the thing that matters.
A count of findings tells you the detector matched something. It cannot tell you that nothing was missed, and it is the missed thing that costs you.
A workflow that holds up
- 1. Take the smallest excerpt that shows the problemA whole log file carries far more than the failure. Fewer lines means fewer secrets to miss, and it makes the report easier to act on.
- 2. Run automated detection firstIt is fast and catches the common shapes — tokens, emails, addresses, credential-style fields. Treat it as a first pass rather than a guarantee.
- 3. Read the result yourself, looking for what it could not knowVendor-specific key formats, connection strings, internal hostnames, customer names, and account identifiers are all sensitive and none of them have an obvious shape. This step is the one that actually protects you.
- 4. Remove context, not only credentialsInternal hostnames, file paths with usernames, and customer identifiers are useful to an attacker and rarely needed to diagnose a bug.
- 5. If a real secret was exposed, rotate itSanitizing the copy you are about to send does not retract the one already sent, pasted, or logged. Rotation is the only action that ends the exposure.
Redaction is not revocation
This is the part most guidance skips. Replacing a key with [REDACTED] changes a string in a text box. It does not contact the provider, does not invalidate the credential, and does not reach the copies that already exist — the terminal scrollback it came from, the shell history, the CI log, the screenshot someone took.
So the decision is not “did I redact it” but “has this value ever been somewhere it should not be”. If it has, rotate it. Sanitizing the next copy is housekeeping; rotation is the fix.
A secret already committed to a repository is the same problem in a harder form: it lives in the history, so deleting it in a later commit changes nothing. That needs history rewriting and rotation, and no text tool — ours included — can help with it.
Sanitize a payload
Paste the excerpt into the Log Sanitizer to see what it finds and redact it. Detection runs entirely in your browser — the payload is never uploaded, which matters more here than for most tools, since the whole point is that it contains something sensitive.
It reports what it matched and leaves the structure intact, so a sanitized JSON payload still parses. It does not claim completeness, and the table above is why.
Measured with
- DataToolsHQ Log Sanitizer —
built-in detection rules
The detection table was produced by running each example through the tool. Detection rules change as they are improved, so treat the table as the behaviour at the time of writing rather than a permanent contract.