Skip to content

🛡 PII / Secret Masker

Automatically detect and mask emails, phone numbers, IPs, credit cards, JWTs, AWS keys, Bearer tokens and other secrets in text. Useful for cleaning logs and screenshots before sharing.

100% Free No signup Browser-only 5 languages Dark mode

🔒 About Privacy (Important)

📖 Where people get stuck

Finds email addresses, phone numbers, IP addresses, card numbers, JWTs, AWS keys, bearer tokens and the like with regular expressions and hides them by replacement, partial masking, deletion or labelling. Everything runs in the browser. Detection only reaches things with a fixed shapezero findings does not mean there is nothing sensitive. Names, addresses and internal identifiers have no fixed form and cannot be caught in principle.

Case What happens What to do
Sensitive data that was not detected simply remains A regular expression can only catch things with a defined format. So names, addresses, internal ticket numbers, identifiers buried inside URLs, Slack channel names, database names and server hostnames all survive untouched. File paths are especially easy to miss: C:\Users\yamada\Desktop\... and /home/tanaka/ contain real names. A stack trace in an error log lays out internal hostnames, the directory layout and the versions of the libraries in use — all of it useful to an attacker. Before you start, list what is actually in the text. Deciding after you see the findings is too late, and you end up believing that only what the tool found was sensitive. With the list in hand, replace by hand anything the tool did not catch — your editor find-and-replace is enough. Then read the masked text from beginning to end with your own eyes; for a long log, read at least the head, the tail and the region around the error. If the point of sharing a log is for someone to diagnose an error, cutting out only the few dozen relevant lines is by far the safest — the full text is almost never needed.
A partial mask narrows the value down for anyone A partial mask such as a***z@example.com or 090-****-5678 can do more to narrow the candidates than to hide the value. A surviving domain reveals the organisation, and surviving last four digits can be matched against the same number seen somewhere else. Card numbers are the sharp case: with the first six digits (the issuer) and the last four intact, one of the six in between is a check digit, so the real search space is five digits — a hundred thousand possibilities. The most dangerous thing about this mode is that the feeling of it is masked, so it is safe arrives before the actual safety does. When you do not control who sees it, choose full replacement or labelling — leaving only the kind, as in [EMAIL] or [CARD], strikes the best balance between readability and safety, since you can still see what stood there and the log keeps its meaning. Partial masking is appropriate only when you, or a small team, need to tell entries apart later. If the goal is to trace which user a log belongs to, the first few characters of a hash are safer than the original value — identity is preserved and the value cannot be recovered. When in doubt, label it: keep information only when you can state the reason for keeping it.
The values are hidden but the structure leaks When the keys survive in a JSON log, a single line reading "user_email": "***" tells you with certainty that an email address was there. If the mask has the same number of characters as the original, the length leaks too — enough to guess the kind of a token, or to narrow the brute-force space for a password. For the same reason, when one value appeared in several places and the masked forms are identical, you have communicated that they are the same value — convenient for tracing a log, but it also hands over the fact that these two requests came from the same person. Drop the key along with the value, or use a label to deliberately flatten the information content: replacing with a fixed-length [EMAIL] removes the length and leaves only the kind. Whether to preserve identity is a choice to make consciously — worth keeping when you are following one user sequence of requests during an incident, but if you are sharing externally, that identity is itself a record of an individual behaviour. The final judgement comes from who will read this text: an internal channel, a public issue and a submission to a vendor tolerate different granularities. Decide the audience first, then choose how hard to mask.

This tool is a last check before publishing, not a substitute for logging design. The real measure is not writing sensitive data into logs in the first place — use structured logging and apply per-field masking at the point of output, which most logging libraries provide a mechanism for. The reason is simple: once written, a log is replicated into your aggregation platform, your backups, your monitoring tools and your alert notifications, and removing it afterwards is effectively impossible. Mask it later is not a workable policy. For screenshots, use the image mosaic tool — but choose the solid black fill rather than a mosaic or a blur. And note that everything on this page runs in your browser and nothing is transmitted, which you can confirm in the Network tab of your developer tools. Make that check a habit for any tool that handles secrets — there is no reason to take a claim of we do not send it on trust alone.

📖 How to Use

  1. 1
    Paste text
    Paste a log line or text from a screenshot into the input area.
  2. 2
    Choose detection types and method
    Toggle the categories you want, then pick a mask method (stars, partial, remove, or label).
  3. 3
    Detect and mask
    Click the button to see the list of detected items and the masked output. Use Copy to send it to your clipboard.

❓ Frequently Asked Questions

Is the text sent to your server?
No. All detection and masking runs in your browser via JavaScript. Because this tool handles secrets, no network traffic is generated at all. You can verify in the Network tab.
How accurate is credit card detection?
We apply the Luhn checksum to 13–19 digit sequences, so false positives are low. However, unusual formatting (separators or spaces) may prevent detection.
Which is safer: partial or full mask?
Full masking (stars or remove) is safest. Partial masking is convenient for debugging when you want to keep things distinguishable, but for highly sensitive items (cards, tokens) use full masking.

🔗 Related Tools

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.

* Browser info (UA / screen / language / URL) is sent automatically to help reproduce the issue