Online logs sanitizer Share the log, not the secrets.

That is one of the main reasons this exists. Because the sanitizing happens in your browser, the log never reaches a third party in raw form — you paste the cleaned output into the assistant instead. Use the “Share with an AI assistant” preset, which is deliberately aggressive: it assumes the log is about to become part of a conversation you cannot delete. Read the output before you send it, because no automated pass understands your data as well as you do.

All of those, out of 53 detectors in total. Password assignments and credentials embedded in URLs collapse to a clear label. Bearer and Basic authorization headers, JSON Web Tokens, PEM private keys, and provider keys — AWS access keys, Google API keys, GitHub and GitLab tokens, Stripe keys, Slack tokens, OpenAI and Anthropic keys, Azure storage keys — are matched on their prefixes and structure. IP addresses, MAC addresses, and hostnames are swapped for stable stand-ins from reserved documentation ranges rather than deleted, so traffic patterns survive. Emails, phone numbers, payment card numbers, IBANs, and national identifiers such as US Social Security numbers are treated as personal data. Every detector can be switched off individually.

No. Detection and replacement run inside your browser, in a Web Worker. In production the page also ships a Content-Security-Policy containing connect-src 'none', which means the browser itself blocks this page from making any network request at all. You can verify that in your developer tools.

Most redaction tools turn every email into [EMAIL_1] and every address into [IP_2], which destroys your ability to group events. This tool replaces an email with a stable fake email, an IP with a stable address from a reserved documentation range, and a UUID with a stable fake UUID. The same input always maps to the same stand-in, so you can still count, group, and diff. Secrets are the exception: those always become clear labels, because nobody correlates on a password.

No. Replacements are allocated through a table that detects a collision and deterministically picks the next candidate, so two distinct originals never merge into one stand-in.

Three ways. Card numbers are checked with the Luhn algorithm and IBANs with mod-97, so ordinary long digit runs are left alone. JSON Web Tokens are confirmed by decoding the header and checking for an alg claim. And when the log is structured, keys are read directly, so authorization is always redacted while token_type stays visible.

Yes. JSON, JSON Lines, and logfmt are parsed so redaction can follow field names rather than guessing from value shapes. Syslog and Common Log Format are recognised and still scanned by every pattern detector.

Not on its own. At the Balanced default, internal identifiers such as user_id, tenant_id, trace_id, and Kubernetes pod names are left readable, because redacting them usually makes a log useless for the debugging you needed it for. Those identifiers can still re-identify a person when combined with other data, so switch to the GDPR preset, the Public issue preset, or simply raise the sensitivity when that matters.

They are saved in this browser only. Export your rules before you clear site data or move to another machine.

The salt makes replacements repeatable, so the same value maps to the same stand-in across every file you clean. Share it with a teammate when you both need matching output for the same incident. Rotate it to break the link with everything you cleaned before.

No. Treat it as compromised and rotate it at the source. A cleaned copy protects the copy you are about to share; it does nothing about the original exposure.