Anonymizer
Detects and masks email, CPF/CNPJ, phone, CEP and password in text, with 3 strategies.
That's why the Anonymizer runs entirely in your browser — the pasted text, the detection and the masked result never leave your computer, not even in passing through a server to produce the output.
Masking strategy
Every occurrence becomes a fixed marker for its type (e.g., "[EMAIL]") — the safest option, but it loses all information about the original value.What this tool does
Paste any text — an application log, a support ticket, an exported conversation — and the tool scans the content for sensitive data patterns (email, CPF, CNPJ, Brazilian phone number, CEP/postal code and password/credential), replacing every match found according to the chosen masking strategy. Useful for sharing a real example with a colleague, pasting into a support ticket, attaching to a bug report, or publishing a log excerpt without exposing a real person's data.
The 3 masking strategies — and when to use each one
Full redaction ("[EMAIL]", "[CPF]") is the safest: no information about the original value survives, ideal for sharing a log publicly or attaching it to an external report. Partial masking ("jo***@***.com", "123.***.***-00") keeps the format, revealing only the minimum of the value — useful when the reader needs to recognize the TYPE of data that was there ("this was an email", "this was a CPF") without seeing the real value; the tool deliberately errs on the side of hiding more, never revealing enough for someone to recognize or infer the original data. Pseudonymization replaces each real value with a fake one, but always the SAME fake value for the same real input throughout the entire text — the best choice when the text mentions the same data multiple times and the relationships between those mentions matter (e.g., a log where the same customer appears several times should still look like the same customer after masking, just with a fictional identifier). Important exception: for password/credential, partial masking ALWAYS behaves like full redaction ("[SENHA]"), never revealing any real character — see "Why password is different", below.
Detected data types and their limitations
Email and CPF/CNPJ use the same full validators as the rest of Nexinon (CPF/CNPJ check digit verified before considering a match valid — an 11-digit sequence with an incorrect check digit is never flagged as a CPF). CEP accepts both the 00000-000 and 00000000 formats. Brazilian phone detection is heuristic, not a complete validation against Anatel's national numbering plan — it recognizes area codes in parentheses or not, with or without separators, mobile (9 digits) or landline (8 digits), with or without the "+55" international prefix, and also recognizes a mobile number without an area code (9 digits starting with 9). One documented exception: an 8-digit landline typed WITHOUT an area code has the exact same format as a CEP without a hyphen (the same 8-digit sequence) — with no textual signal to tell the two apart, the tool resolves in favor of CEP, the more common case for a standalone 8-digit sequence in free text. Being heuristic, the phone detector can occasionally miss an unusual format (false negative) or flag a numeric sequence that isn't actually a phone number (false positive) — always review the result before sharing sensitive text.
Why password is different from the other 5 types
Email, CPF, CNPJ, phone and CEP all have a FORMAT of their own — a checksum to verify, a recognizable structure, an expected digit count. A password has no format at all: it can be any sequence of characters, of any length. So the only possible detection is by CONTEXT — a known label ("senha", "password", "pwd" or "pass", case-insensitive) followed by a delimiter (":" or "=") and a value that runs to the end of the line. With no "check digit" for passwords to verify, this is the most heuristic detection in the catalog — higher risk of both false positives (a label used for something else, e.g., "WiFi password: ask the front desk") and false negatives (a password mentioned without any of the recognized labels, e.g., "the access key is 123") than any of the other five types. Two label occurrences on the same line, with no line break between them, also aren't separated — the first one's "to end of line" capture consumes the second entirely, turning them into one combined match (still safe — no original text is ever left exposed, just less granular than ideal).
Why local execution matters especially here
In every Nexinon tool, local execution means privacy — here it's the whole reason the tool exists. The text you paste to anonymize IS the sensitive data: sending it to a server for processing, even just in passing, would defeat the purpose before the masking even happens. That's why the Anonymizer never makes any network call — scanning, validation and replacement all run entirely in your browser, from the first character pasted to the last character copied.
Frequently asked questions
No. The Anonymizer runs 100% in your browser — no pasted text, and no masked result, is ever sent to any server.
Full redaction when the original value doesn't matter at all (e.g., a public log). Partial masking when the reader only needs to recognize the TYPE of data ("this was an email/CPF/phone number") without seeing the real value. Pseudonymization when the same data appears multiple times in the text and the relationships between occurrences ("this is the same customer/user") need to remain visible after masking.
Not across different runs — only within the SAME processing pass. If you paste the same email twice in the same text, both occurrences become the same fake value in that pass; but processing the text again later (or a different text with the same email) may produce a different fake value, since the mapping is built from scratch on every run.
Because the detector checks the check digit before flagging something as a CPF — the same validation used by the CPF/CNPJ Generator. A random 11-digit sequence (e.g., a protocol number) almost never passes that check, so it isn't masked as a CPF; depending on the format, it may still be recognized as a possible phone number, since the phone detector is more permissive.
It's a heuristic, not a complete validation against Anatel's numbering plan. It covers the most common formats found in free text (with/without area code, with/without separators, mobile with or without area code, landline with area code, with/without +55), but it can occasionally miss an unusual format or mistakenly flag a numeric sequence that isn't a phone number — always review the result before sharing anything sensitive.
Because, without an area code, an 8-digit landline and a CEP without a hyphen have the exact same format — there's no signal in the text that reliably tells the two apart. Faced with that genuine ambiguity, the tool picks CEP, since it's the more common case for a standalone 8-digit sequence in free text. A mobile number without an area code (9 digits, starting with 9) doesn't have this problem — 9 digits never collides with the CEP format.
Not in this version — the scope covers email, CPF, CNPJ, Brazilian phone numbers, CEP and password/credential. Other types (national ID, credit card, IP address, license plate) remain a possible future addition.
By context, not by format — it's the only one of the six types that works this way. The tool looks for a known label ("senha", "password", "pwd" or "pass", case-insensitive) followed by ":" or "=", capturing everything to the end of the line as the value. With no format validation possible (unlike the CPF's check digit, for example), this is the most heuristic detection in the tool — it only works when the text uses one of the recognized labels.
A deliberate decision: for the other five types, revealing a small fragment (e.g., the last 2 digits of a phone number) is a small, acceptable privacy loss. For a password, every real character exposed genuinely reduces the search space of a brute-force attack against that specific credential — it's not the same kind of risk, so it doesn't get the same treatment. That's why password always falls back to the "[SENHA]" marker (the same one full redaction uses), even with "Partial masking" selected.
No. All three strategies are one-way — full redaction and partial masking discard part or all of the original value, and pseudonymization generates a fake value with no reversible link to the original. Keep the original text separately if you'll need it later.
CEP adds very little implementation cost (the same digit format as CPF, with no check digit to validate) and shows up often in real logs/tickets next to an address. National ID (RG) has no single reliable national format to detect via regex, and credit card numbers would need their own security discussion (they should never appear in free text, and Nexinon avoids building detection that might look like it endorses pasting that data anywhere) — candidates for a future version, not an oversight.
Nexinon Principles
Privacy
Your data never leaves your browser.No account needed
Use it now, no account or password.Free
No usage limits, no paid plan.Trustworthy content
Full explanation behind every tool, not just the result.