Guide
Removing secrets and personal data from logs before sharing them
Logs, stack traces and config files are the first things people paste into support tickets, forums and AI chats, and they are full of things that should stay private: API keys, session tokens, passwords in connection strings, customers’ email addresses and IP addresses. This tool finds those patterns and replaces them with placeholders, so what you share still shows what went wrong without showing who or how to log in.
What it finds
The rules fall into three groups. Credentials include JSON Web Tokens, AWS access keys, GitHub tokens, Stripe and Slack keys, Google API keys, keys starting with sk-, PEM private-key blocks, Bearer and Basic authorisation headers, passwords inside URLs such as postgres://user:password@host, and values after names like password, secret, token or api_key. Personal data covers emails, IPv4 and IPv6 addresses, payment cards and phone numbers in international format. UUIDs can be masked too, which helps when identifiers could link records to people.
Numbered placeholders
The same value always becomes the same placeholder when the consistency option is on: the first email is [EMAIL_1], the second [EMAIL_2], and every later occurrence of the first keeps _1. That keeps the story of the log intact. You can still see that one user logged in, failed twice and logged out, without knowing who it was. With the option off, every match becomes a fixed label like [EMAIL], which is shorter but hides repetition.
Avoiding false positives
Long numbers appear in logs for harmless reasons. Card-like digit sequences are only replaced if they pass the Luhn checksum that real card numbers satisfy, so order numbers and timestamps stay readable. IPv6 and UUID matching is off by default because they also match timestamps, hashes and identifiers that are often needed to debug. Switch rules on or off with the chips, and the counts show how many replacements each rule made.
A worked example
The Sample is six log lines. The result replaces the repeated email with [EMAIL_1] in both lines, the IP address with [IP_1], the JWT in the Authorization: Bearer header with [JWT_1], the AWS key with [AWS_KEY_1], the card number with [CARD_1] and the phone number with [PHONE_1]. The database URL becomes postgres://app:[PASSWORD]@db.internal:5432/shop, keeping the host and port for debugging while dropping the password. The UUID stays, because that rule is off by default.
What pattern matching misses
Only formats the rules know are caught. A custom token with no recognisable prefix, a password in free text, a customer’s name, an internal host name, an address or a medical detail will pass through unchanged. Read the output before sharing it, search it for anything that looks like a credential, and prefer sharing the smallest excerpt that shows the problem.
If a secret has already leaked
Redacting a log you have already posted does not undo the exposure. Pages and chats are cached, indexed and copied, and automated scanners look for leaked keys within minutes. Revoke or rotate the credential at the provider, check its recent use, and only then clean up the post. For personal data, you may have notification duties under data protection law.
Privacy
The text is processed in the page and never uploaded; the input is deliberately not saved in the browser, so closing or reloading the tab removes it. Do not rely on any single tool as the only safeguard when the data is highly sensitive.
Related tools
- HAR Analyzer opens network captures, which hold cookies and tokens that this tool can mask.
- Access Log Analyzer summarises logs whose IP addresses you may want to remove first.
- Anonymize CSV Data masks personal columns in spreadsheets.
- JWT Decoder shows what a token contains before you decide to share it.
Checked against the current version of the Redact Log Secrets on .