Log Masker & Sensitive Data Anonymizer
Paste logs or text to automatically detect and redact sensitive data — emails, IP addresses, API keys, tokens, passwords, credit cards, phone numbers and custom regex patterns. Everything runs in your browser; nothing is sent anywhere.
What is a Log Masker?
A log masker (also called a log sanitizer or PII redactor) automatically detects and replaces sensitive data in log output with safe placeholder values, making the logs safe to share, store in external systems, or include in bug reports. Sensitive data such as email addresses, API keys, credit card numbers, passwords, and JWT tokens routinely end up in application logs — often unintentionally — creating significant privacy and security risks when those logs are forwarded to third-party log aggregation services, shared with support teams, or retained beyond their necessary lifecycle.
GDPR, HIPAA, PCI DSS, and most modern data privacy regulations impose strict requirements on how personal data in logs must be handled. Masking logs before export or analysis is one of the most practical ways to reduce compliance risk without having to instrument every single log call in your codebase. It is also an essential step in secure debugging workflows — before pasting logs into a Slack channel or a GitHub issue, running them through a masker ensures that real customer data is never inadvertently exposed.
When to Use This Tool
- Before sharing logs with third parties: Sanitize log excerpts before attaching them to support tickets, vendor escalations, or GitHub issues so that customer emails, IPs, and authentication tokens are not exposed to parties outside your organization.
- Before exporting to external log platforms: When setting up a new log pipeline to a third-party SIEM or log aggregation service (Datadog, Splunk, Elastic), use this tool to test that your masking rules correctly redact all sensitive field patterns before enabling the live integration.
- During incident debugging in privacy-sensitive environments: In healthcare or fintech environments where engineers may not be authorized to view raw PII, masked logs allow debugging to proceed without granting broad data access.
- Validating custom regex masking rules: Test and iterate on custom regular expressions against real log samples before deploying them to a production log processor, ensuring they match the intended patterns without false positives.
How It Works
The tool applies a library of pre-built regular expressions — each tuned to match a specific type of sensitive data — to your input text using JavaScript's String.prototype.replace() with global flag matching. Each matched value is replaced with the selected masking style: a labelled placeholder, asterisks, a deterministic hash derived from the original value (useful for correlation without exposure), or a partially-revealed form. Custom regex patterns can be added at runtime to match application-specific secrets such as internal user IDs, session tokens, or proprietary API key formats.
Frequently Asked Questions
What types of sensitive data does this tool detect?
The tool detects and masks a comprehensive set of PII and secret data types including email addresses, IPv4 and IPv6 addresses, JWT tokens (the eyJ... format), Bearer tokens in HTTP headers, generic API keys matching common patterns (api_key=, api_token=, access_token=), AWS access key IDs (AKIA...), AWS secret access keys, credit card numbers (Visa, Mastercard, Amex, Diners), US Social Security Numbers, phone numbers in common formats, private key PEM blocks, URLs containing embedded credentials (user:password@host), MAC addresses, and high-entropy hex strings of 32 or more characters. You can also define custom regex patterns to catch application-specific secrets.
Is my log data sent to a server?
No. All masking happens entirely in your browser using JavaScript regular expressions — no network request is made when you paste logs or click to mask. Your log data never leaves your device, which makes this tool safe to use with production logs that contain real customer data or internal secrets. You can verify this by opening your browser's developer tools Network tab and observing that no outbound requests are made during masking operations. This client-side design is an intentional security decision: sending log data to a server for processing would itself create the type of data exposure the tool is meant to prevent.
What masking styles are available and when should I use each?
Four masking styles are available. [REDACTED_TYPE] replaces each match with a labelled placeholder (e.g. [REDACTED_EMAIL]), preserving information about what type of data was present — best for audit logs and compliance documentation. ***masked*** produces a compact, visually obvious redaction marker suitable for human-reviewed log excerpts. sha256(value) produces a deterministic hash token derived from the original value: the same secret produces the same hash every time, enabling you to correlate occurrences of the same value across multiple log lines without revealing the underlying data — useful for analytics and debugging. Partial masking preserves the first and last characters while replacing the middle with asterisks (e.g. jo***@example.com), mimicking how payment terminals display card numbers, which aids debugging while reducing exposure.