Log Masker & Sensitive Data Anonymizer

When the Masked Log Still Isn't Safe to Share

The first thing to check when a masking pass looks suspicious is whether the output still contains anything resembling the original patterns after the fact — search the masked result for @ symbols, sequences of digits four characters or longer, or the string Bearer to catch a value the built-in regex library didn't recognise. If a value survives masking, the most common cause is a non-standard internal format: a proprietary session token or internal identifier that doesn't match any of the generic api_key=, AWS-key, or JWT patterns the tool ships with — the fix is adding a custom regex tuned to that specific format rather than assuming the default library is exhaustive. A second, subtler failure mode shows up specifically with structured logs: if the input is JSON lines and a masking regex matches across a quoted-string boundary, the output can come out as syntactically broken JSON — always re-validate that masked structured logs still parse correctly before piping them into a JSON-aware log viewer or shipping them onward. If correlation between log lines seems to have vanished after masking, that's usually not a bug — asterisk-style masking intentionally destroys the ability to tell whether two masked lines came from the same original value, which calls for switching to the deterministic hash style instead.

The sed and grep Version of This Same Job

Everything this tool does is, at its core, a set of regular expressions applied with global replacement — the same operation sed performs on the command line. A single pattern, like masking email addresses, translates directly to something like sed -E 's/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/[REDACTED_EMAIL]/g' piped over a log file. The practical difference is maintenance and coverage: this tool ships a curated library of a dozen-plus pre-tested patterns — emails, IPv4 and IPv6 addresses, JWTs, AWS keys, credit card numbers, and more — that would otherwise mean hand-maintaining and testing a dozen separate sed expressions, each with its own edge cases around anchoring and escaping. For a one-off log excerpt before a support ticket, pasting into this tool is faster than writing and debugging a regex from scratch; for a repeatable pipeline step processing thousands of log lines a day, the equivalent logic belongs in a compiled script or a log-processor plugin, not a manual paste-and-copy loop.

Redacting a Vendor Support Log, Start to Finish

Say a third-party integration is failing and the vendor's support team needs to see the actual log output, including a stack trace with an embedded auth header and a couple of customer email addresses. First, paste the raw log block into the input panel exactly as captured, without pre-editing it. Second, pick a masking style deliberately: for a support ticket where the vendor needs to know what type of data was present without seeing its value, the labelled placeholder style ([REDACTED_EMAIL], [REDACTED_JWT]) communicates more than a plain asterisk mask would. Third, run the masking pass and manually scan the result for anything that looks like it slipped through — a proprietary internal token format is the most likely gap. Fourth, paste the masked output into the ticket. The entire operation happens client-side, so the unmasked log data is never transmitted anywhere during the process — only the redacted version you explicitly copy out ever leaves the browser tab.

Rules for Sharing Logs Without Regretting It Later

• Keep an unmasked copy in your access-controlled primary log store: Masking is one-way — once a value becomes a placeholder or hash, the original is gone from that copy, so only mask the export you intend to share externally, never your source of truth.
• Default to labelled placeholders for compliance-facing exports: An auditor or vendor reviewing a redacted log benefits from knowing what category of data was present at each redaction, which a generic asterisk mask doesn't convey.
• Use the deterministic hash style whenever you need to track repeated occurrences: If the investigation depends on knowing whether the same user or key appears across multiple log lines, hash-based masking preserves that correlation while asterisk masking destroys it.
• Test custom patterns against real captured samples, not synthetic ones: A regex that looks correct against a hand-written test string can still miss the actual formatting quirks of your production log lines — validate it against a genuine excerpt before relying on it.

Frequently Asked Questions