Skip to main content

Log Sanitizer

Available
Security

Paste or upload application, server, API, or security logs and automatically detect and mask emails, IPs, API keys, JWTs, passwords, credit cards, and dozens of other sensitive patterns - with a reversible mapping table and custom rules, entirely in your browser.

Log Sanitizer tool

Original Log

0 chars · 0 B

Paste raw application, server, API, or security logs - Windows Event JSON, Syslog, CEF, LEEF, Apache, Nginx, or plain text all work.

Cleaned Log

Sanitized, copy-ready log output. Edit rows in the mapping table below to fine-tune it.

Mapping Table

Every detected value, its masked form, and its original value. Swap individual rows to a placeholder token (e.g. [EMAIL_1]) or revert them back to the original - the Output panel above updates instantly.

Run Sanitize to build the mapping table.

Statistics

What was detected and masked.

Run Sanitize to see detection statistics.

Choose what to hide

39/39 on

Turn off anything you want to keep visible in the cleaned copy.

Strict also catches higher-noise patterns (Aadhaar/PAN-style numbers, long hex/base64 blobs) that "Readable" leaves alone to reduce false positives.

Custom things to hide

Add private names, tenant IDs, workspace IDs, emails, or patterns once. This browser remembers them for next time - export the rules before clearing browser data or moving to another device.

Add custom rule

A pasted log carries more than the error you meant to share

Alongside the stack trace, it's easy to hand over personal data, live credentials, and internal service names that were never meant to leave your systems.

Assistants remember more than you'd like

An AI chat holds onto whatever context you feed it - scrub the log before it becomes part of that conversation.

Tickets and threads outlive the moment

Once a log lands in a GitHub issue, Slack channel, or support thread, it can be copied, indexed, and archived far longer than you intended.

Assume a leaked value is compromised

Any genuine password, cookie, or token spotted in a log should be rotated at the source - a cleaned copy doesn't undo the original exposure.

What this pass takes care of

Strip out personal details

Emails, phone numbers, IP addresses, and account or customer identifiers get pulled before anything leaves your machine.

Neutralize credentials on sight

API keys, bearer tokens, cookies, auth headers, and local file paths are swapped for clear, labeled stand-ins.

Leave the diagnostics alone

Status codes, timestamps, stack traces, and error text stay exactly as written, so nothing useful for debugging disappears.

Nothing leaves the tab

Every pass over your text or uploaded file happens inside this browser session - there's no upload step to skip.

From raw paste to ready-to-send in three moves

01

Drop in the raw log

Paste text directly, or hand over a .log, .txt, or .json file - either lands in the same editor.

02

Dial in the cleanup

Switch between Readable and Strict passes, flip categories on or off, and layer in any custom patterns your setup needs.

03

Confirm, then hand it off

Walk through the stats and mapping table, expand to fullscreen if it's long, and copy or export once it checks out.

Want the full checklist, or answers to common questions? Read the guide to removing secrets from logs or check the Log Sanitizer FAQ.

How to use the Log Sanitizer

  1. Paste a log into the input box, or open a .log, .txt or .json file.
  2. Choose what to detect. The defaults cover most cases; switch categories off if you want to keep something readable.
  3. Pick a cleaning strength: Readable keeps the shape of values so the log is still easy to follow, Strict masks more aggressively.
  4. Run the sanitizer, then read the output and the mapping table before copying it.
  5. Add a custom rule if your organisation has an identifier the built-in detectors cannot know about.
What you enter
Raw text from an application, server, API or security log. Any plain-text format works, including JSON lines, key=value logs, syslog and stack traces.
What you get
The same text with sensitive values replaced by masked values, a count of what was found by category, and a mapping table that lets you see which placeholder stands for which kind of value.

Who it is for

  • Developers attaching logs to bug reports, support tickets or issues
  • Support and operations staff forwarding customer logs to a vendor
  • Anyone about to paste a log into a chat, a forum or an AI assistant

Examples

A request log with a token and an address

2026-10-01T09:14:02Z INFO [email protected] ip=203.0.113.42 Authorization: Bearer eyJhbGciOi...

The email address, the IP address and the bearer token are each replaced with a masked value, while the timestamp, level and field names stay, so the line still shows what happened.

A connection string in a stack trace

Failed to connect: postgres://appuser:[email protected]:5432/orders

The password in the connection string is masked. Depending on the categories you leave enabled, the internal host name can be masked too.

Key concepts

Masking versus redaction
Masking replaces part or all of a value with placeholder characters but keeps its shape, which helps you tell two different users apart. Redaction removes the value entirely. The Readable and Strict modes sit on that spectrum.
Why logs contain sensitive data
Logs record what software saw. Request URLs carry query strings with tokens, headers carry credentials and cookies, error messages echo user input and connection strings, and debug output often prints whole objects. Nobody decided to log a password; it was inside something that was logged.
Identifiers are personal data too
Email addresses, phone numbers and IP addresses can identify a person even when no name is present, and session IDs and device identifiers can let someone act as them. They deserve the same care as an obvious secret.

Common use cases

  • Support tickets and vendor support: send enough to reproduce a problem without handing over customer data.
  • GitHub issues and Stack Overflow questions: public posts are permanent and indexed.
  • Slack, Teams and email: messages are copied, forwarded and searched long after the incident.
  • AI assistants: pasted text may be stored under the provider's terms.
  • Incident reports and post-mortems that will be read by a wider audience than the responders.

Common mistakes

Sharing the output without reading it
Detectors work from patterns. Read the result once before it leaves your hands, especially free-text fields and unusual identifiers.
Treating a masked copy as proof the secret is safe
If a real credential was ever in a log that left your control, assume it is exposed and rotate it. Masking the copy does not un-leak the original.
Switching off categories to make the log shorter
Turning detectors off keeps those values in the output. Disable a category only when you are sure the value is harmless.
Forgetting values that are specific to your system
Internal customer IDs, project codenames and host naming schemes are invisible to a general tool. Add a custom rule for them.

Limitations

  • No detector is perfect. Unusual secret formats, secrets split across lines, and sensitive data written in prose can be missed, and some harmless values can be masked by mistake.
  • The tool masks what it recognises. It does not understand your business context or legal obligations.
  • Very large inputs are truncated for processing, and the tool tells you when that happens.
  • It is an aid to careful review, not a compliance guarantee.

Results are an aid, not a guarantee. Please read the Disclaimer.

Troubleshooting

A secret was not masked
Check that the matching category is enabled, try Strict mode, or add a custom rule with a pattern for that format. Then report the format on the Contact page so detection can improve.
Too much was masked and the log is hard to read
Use Readable mode and turn off categories such as host names or UUIDs if you need them to follow the flow.
A file will not open
Use .log, .txt or .json files under the size limit, or paste the text instead.

Privacy

The Log Sanitizer page runs in your browser. The log you paste or open is not sent to DevCraftKit. Custom rules you create are saved in your browser's local storage on your device. Reloading the page clears the input. Full details are in the Privacy Policy.

Related guides

Did Log Sanitizer save you from manually cleaning a giant log?

If these free developer tools save you time, consider buying me a byte. Your support helps keep DevCraftKit free and growing.

Buy me a byte 💾

Resources

View all

Explore more developer tools

Browse the full collection, or see everything in Security.

Found a bug or an incorrect result in Log Sanitizer?

Report it, or suggest an improvement. Messages go straight to the developer.

Send feedback