CSV Data Masking & Anonymizer
Mask emails, phone numbers, and card numbers in CSV columns using regex — entirely in your browser.
Your CSV stays in this tab — it is never uploaded and never added to the page URL, so a shared link can’t leak it.
How CSV data masking works
This tool parses a CSV file into rows and columns, then applies regex-based masking rules to the columns you choose. Paste CSV text or drop a file, and each column header is scanned to guess a sensible mask type automatically — column names containing “email” default to email masking, “phone” or “mobile” default to phone masking, and “card” or “credit” default to card masking. You can override any column’s mask type from the dropdown.
Email masking keeps the first character of the local part and the full domain, replacing the rest with asterisks (e.g. j***@example.com). Phone masking keeps the last two digits and masks the rest. Card number masking keeps the last four digits, matching the common “last 4” display convention used by payment processors. Generic masking hides everything except the last four characters of a field, useful for IDs, tokens, or any other sensitive value.
All parsing and masking happens locally in your browser using JavaScript regular expressions — your CSV data is never uploaded to any server, which makes this safe to use on real customer data, test fixtures, or exports that contain personally identifiable information (PII) before sharing them with a team, committing them to a repo, or using them in a demo.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Masking an export before sharing it with a vendor or attaching it to a ticket.
- Producing a realistic-looking test dataset from production data without carrying the personal data with it.
- Redacting one column of a spreadsheet while leaving the rest intact for analysis.
- Checking which columns in an unfamiliar export actually contain identifiers.
- Preparing a sample for a bug report without the sensitive fields.
Frequently Asked Questions
- What does anonymising a CSV involve?
- Replacing or masking the columns that identify a person — names, emails, phone numbers, IDs — while keeping the structure intact so the file is still usable. The hard part is deciding which columns those are, not performing the replacement.
- Is masking direct identifiers enough?
- No. Quasi-identifiers combine: postcode, birth date and sex uniquely identify most of a population, which is how supposedly anonymised datasets have been re-identified repeatedly. Removing names is necessary and a long way from sufficient.
- What is k-anonymity?
- The property that every record is indistinguishable from at least k−1 others on the quasi-identifiers. Achieving it means generalising — a birth year instead of a date, a region instead of a postcode — which trades analytical precision for real protection.
- What is the difference from pseudonymisation?
- Pseudonymisation replaces identifiers with tokens and is reversible with the mapping, so under GDPR the data is still personal. Anonymisation must be irreversible to take data out of scope, and consistent tokens across a file rarely meet that bar.
- Does the file leave my machine?
- No — the processing runs in your browser. That matters more here than almost anywhere else, since the input is by definition a file containing the personal data you are trying to protect.
Common errors and gotchas
- Masking the obvious columns and leaving a free-text field that contains the same data.
- Assuming masking is anonymisation. A small dataset can often be re-identified from the remaining columns.
- Using a consistent replacement per value, which preserves the ability to link records back together.
- Forgetting the header row or a footer, which can carry identifying information of their own.
- Overlooking that a quoted field containing commas may be split by a naive column selection.