How to auto-redact emails, phone numbers, and ssns from excel files
- Step 1Open the redactor — The Excel PII Redactor opens the in-browser Email & Phone Scrubber, which accepts
.xlsx,.xls,.ods,.csv, JSON, Markdown, and plain text. - Step 2Drop your spreadsheet — Drag the file in. SheetJS parses it locally — nothing is uploaded. Only the first worksheet is read and flattened to a JSON array of rows.
- Step 3Let the six detectors run — Email, IBAN, credit card, US SSN, UK NI, and phone patterns are applied in order. IBANs and cards must pass their checksums; SSNs must clear the SSA invalid blocks.
- Step 4Read the per-category counts — The findings panel shows how many of each category were replaced and the total redacted, so you can sanity-check coverage before exporting.
- Step 5Download the scrubbed file — You get
<name>-scrubbed.<ext>— the scrubbed first-sheet data as text/JSON with each match swapped for its fixed[REDACTED_*]label. - Step 6Handle what the patterns can't — Drop or generalise free-text name/address columns yourself, then clear extra tabs and metadata with the sibling Privacy Vault tools before sharing.
What the scanner actually detects (and how)
The six built-in detectors, in the exact order they run. Order matters: specific number patterns (IBAN, card, SSN, NI) run before the generic phone matcher, because each is a subset of 'a run of digits with optional spaces'. Tags are fixed literal strings — there is no mask-format option in this tool.
| Detector | What matches | Validation | Replacement tag |
|---|---|---|---|
local@domain.tld — letters/digits/._%+- before @, a dotted domain, 2+ letter TLD | Pattern only (no MX/syntax-strict RFC check) | [REDACTED_EMAIL] | |
| IBAN | 2 letters + 2 check digits + 4–7 groups of alphanumerics, spaces allowed | ISO 13616 mod-97-10 checksum — fails the check, left untouched | [REDACTED_IBAN] |
| Credit card | 13–19 digits with optional spaces or dashes between them | Luhn checksum — fails Luhn, left untouched | [REDACTED_CARD] |
| US SSN | NNN-NN-NNNN with SSA invalid-block exclusions (no 000/666/9xx area, no 00 group, no 0000 serial) | Structural rules baked into the pattern | [REDACTED_SSN] |
| UK NI number | Two prefix letters + 6 digits + a final A–D letter, e.g. QQ 12 34 56 C | Excludes the disallowed prefixes (BG, GB, NK, KN, TN, NT, ZZ) | [REDACTED_NI] |
| Phone | +CC optional, then 2–4 digit groups separated by space/dot/dash — broad international shape | Pattern only; runs last so card/SSN/IBAN claim their digits first | [REDACTED_PHONE] |
Input, output, and tier limits
The Excel PII Redactor entry routes to the Email & Phone Scrubber, which reads the spreadsheet, flattens the first worksheet to text, scrubs it, and hands back a text file. Tier numbers shown are the Excel family caps from the pricing model.
| Property | Behaviour |
|---|---|
| Accepted inputs | .xlsx, .xls, .ods, .csv, plus pasted/dropped JSON / Markdown / TXT |
| What gets read | The first worksheet only — it is converted to a JSON array of row objects, then scanned |
| Output | A text file named <yourfile>-scrubbed.<ext> (the scrubbed JSON/text), not a rebuilt .xlsx workbook |
| Findings | Per-category counts (email, iban, credit_card, ssn_us, ni_uk, phone) plus a total itemsRedacted — no per-cell address log |
| Configurable options | None. There is no options panel, no custom-regex field, no mask-format picker — the six detectors and their tags are fixed |
| Free tier (Excel family) | 5 MB file, 10,000 rows, 1 file at a time |
| Pro / Pro-media / Developer | 50 MB · 100,000 rows · 5 files / 200 MB · 500,000 rows · 20 files / 500 MB · unlimited rows |
| Where it runs | 100% in your browser — the spreadsheet is never uploaded to a server |
Cookbook
Real before/after rows showing exactly which cells the six detectors claim — and which they leave alone. Values are illustrative.
A typical CRM row with three live identifiers
Email, US SSN, and a US phone all get distinct tags in a single pass. The order column is a Luhn-failing number, so it is preserved.
Input (first sheet, JSON-flattened):
[
{ "Name": "Dana Reyes", "Email": "dana.reyes@acme.io",
"SSN": "234-56-7890", "Phone": "+1 415-555-0142",
"OrderID": "4111111111111234" }
]
Output (-scrubbed):
[
{ "Name": "Dana Reyes", "Email": "[REDACTED_EMAIL]",
"SSN": "[REDACTED_SSN]", "Phone": "[REDACTED_PHONE]",
"OrderID": "4111111111111234" }
]
Counts: { email: 1, ssn_us: 1, phone: 1 } total redacted: 3
(OrderID kept — fails the Luhn check, so not treated as a card.)Invalid SSN blocks are skipped on purpose
The SSN pattern bans 000/666/9xx areas, the 00 group, and the 0000 serial. Placeholder/test SSNs in those blocks pass straight through.
Input:
Valid SSN: 123-45-6789
Test SSN: 000-12-3456
Test SSN: 666-45-6789
Output:
Valid SSN: [REDACTED_SSN]
Test SSN: 000-12-3456
Test SSN: 666-45-6789
Counts: { ssn_us: 1 }A real card is caught; a typo'd card is not
Both are 16 digits, but only the Luhn-valid one is redacted. The other is left intact rather than risk mangling a non-card value.
Input:
Card A: 4242 4242 4242 4242
Card B: 4242 4242 4242 4243
Output:
Card A: [REDACTED_CARD]
Card B: 4242 4242 4242 4243
Counts: { credit_card: 1 }Phone runs last and is broad
International and US formats both match the loose phone shape. A bare extension glued to text may not.
Input:
Mobile: +44 20 7946 0958
Direct: (415) 555 0142
Ext: x4477
Output:
Mobile: [REDACTED_PHONE]
Direct: [REDACTED_PHONE]
Ext: x4477
Counts: { phone: 2 }Names and addresses are NOT detected
No NLP here — only pattern-and-checksum detectors. Free-text identity columns survive and must be handled separately.
Input:
{ "Customer": "Jordan Blake", "Address": "14 Mill Lane, Leeds",
"Email": "jordan@blake.co.uk" }
Output:
{ "Customer": "Jordan Blake", "Address": "14 Mill Lane, Leeds",
"Email": "[REDACTED_EMAIL]" }
Drop or generalise Customer/Address yourself before sharing.Edge cases and what actually happens
Card or SSN-shaped number that fails its checksum / structure
PreservedCredit-card detection only fires when the digit run passes the Luhn checksum, and IBAN only when the mod-97-10 check passes. A 16-digit order number or a typo'd card that fails Luhn is left exactly as-is. An SSN-shaped value in a banned block (e.g. 000-12-3456 or 666-...) is likewise skipped by design — those are never valid SSNs.
Only the first worksheet is scanned
By designThe reader flattens wb.SheetNames[0] to text and scrubs that. PII sitting on a second tab (a hidden 'Contacts' sheet, an 'Audit' tab) is not touched. Split multi-tab workbooks first, or scrub each sheet's data separately, and remember to clear residual sheets with the hidden-sheet destroyer.
Output comes back as text, not a workbook
ExpectedFeeding an .xlsx in does not return an .xlsx out. The first sheet becomes a JSON array of row objects, the scrub runs, and you download <name>-scrubbed.xlsx whose contents are scrubbed text/JSON. Treat it as a redacted data dump, not a styled, multi-sheet workbook — formulas, formatting, and extra tabs are gone.
Phone numbers in an unusual local format
May missThe phone matcher targets a broad international shape (+CC then 2–4 digit groups split by space/dot/dash). Tightly packed or unusually punctuated locals (e.g. parenthesised area codes glued to text, vanity numbers like 1-800-FLOWERS) can slip through. Check the per-category count after a run and spot-check the output.
A full name or street address in a cell
Not detectedThere is no name/address NLP here — the six detectors are all pattern-and-checksum based. John Smith, 14 Mill Lane stays in the clear. For free-text identifiers you must redact those columns by other means (drop the column, or generalise it) before sharing.
Email-like token inside a URL or file path
RedactedThe email pattern matches anything shaped like local@domain.tld regardless of context, so mailto:sam@acme.io and //user@host.example/path both get the address portion replaced with [REDACTED_EMAIL]. This is usually what you want, but it can rewrite a host string you meant to keep.
Numbers run last — phone can swallow a near-miss
By designBecause the generic phone pattern runs after IBAN/card/SSN/NI, any long digit group those earlier detectors rejected (failed Luhn, wrong block) is still eligible to match as a phone number if it fits the loose phone shape. Review counts if a value you expected to keep was tagged [REDACTED_PHONE].
File over the tier row/byte cap
RejectedA Free-tier scan stops at 5 MB / 10,000 rows / 1 file. Larger exports return a limit error before any scrubbing runs. Split the export, trim to the needed columns, or move to a higher tier (Pro 50 MB / 100k rows, Developer 500 MB / unlimited).
UK NI number with disallowed prefix
Not detectedThe NI matcher excludes the prefixes BG, GB, NK, KN, TN, NT, and ZZ because they are never issued. A value like ZZ 12 34 56 C is skipped — it is not a valid NI number. Real NI numbers (QQ 12 34 56 A) are redacted as [REDACTED_NI].
Frequently asked questions
What exactly gets replaced, and with what?
Six categories: emails, IBANs, credit-card numbers, US SSNs, UK National Insurance numbers, and phone numbers. Each is swapped for a fixed label — [REDACTED_EMAIL], [REDACTED_IBAN], [REDACTED_CARD], [REDACTED_SSN], [REDACTED_NI], [REDACTED_PHONE]. The tags are not configurable.
Can I add my own regex or change the mask string?
No. This tool has no options panel — the detectors and their replacement tags are fixed in code. If you need custom patterns or realistic fake values, generate substitutes downstream (e.g. with a Faker-based scrambler) rather than expecting per-pattern masks here.
Does it produce a redacted .xlsx workbook?
No. It reads the first worksheet, flattens it to a JSON array of rows, scrubs that text, and gives you a <name>-scrubbed.<ext> text download. It is a redacted data export, not a rebuilt styled workbook with all sheets and formulas intact.
Are credit cards and IBANs really validated, not just pattern-matched?
Yes. Card numbers must pass the Luhn checksum and IBANs must pass the ISO 13616 mod-97-10 check before they are redacted. Values that fail are left untouched, which keeps order numbers and SKUs from being mangled — but also means a malformed card slips through.
Does my spreadsheet get uploaded anywhere?
No. Detection and replacement happen entirely in your browser. The file is parsed locally with SheetJS and scrubbed in memory — nothing is sent to a server, which is the whole point for sensitive exports.
Is the redaction reversible?
No. Matched values are overwritten with a label; the original digits/characters are gone from the output. Always keep the source file in a secure location if you might need to reverse-map redacted records.
Will it scan every tab in my workbook?
No — only the first worksheet is read. Move other tabs' data into the first sheet, or run the tool once per sheet. Afterwards, strip leftover tabs with the hidden-sheet destroyer so no unscrubbed data ships in the file.
Why did a number I wanted to keep get redacted as a phone?
The phone pattern is deliberately broad and runs last, so any long digit group that earlier detectors rejected can still match it. Check the per-category counts; if phone is higher than expected, your data has digit runs that fit the loose phone shape.
Why did a real card / SSN slip through?
Cards must pass Luhn and SSNs must fall outside the SSA-invalid blocks to be redacted. A card with a typo'd digit fails Luhn; an SSN-shaped value in a banned area/group/serial is treated as not-an-SSN. The validation that avoids false positives also means malformed values are kept.
What are the size and row limits?
Excel-family caps apply: Free 5 MB / 10,000 rows / 1 file; Pro 50 MB / 100,000 rows / 5 files; Pro-media 200 MB / 500,000 rows / 20 files; Developer 500 MB / unlimited rows. Oversized files are rejected before scrubbing.
What other privacy tools should I run alongside this?
Strip document metadata with the app-metadata wiper, remove cell comments via the comment purger, and check for data-leaking links with the external-link auditor. Together they cover content, metadata, and references.
Is this the same engine as the Email & Phone Scrubber?
Yes. The Excel PII Redactor entry points at the Email & Phone Scrubber; it is the same detection pipeline, just fed by a spreadsheet that is flattened to text first.
Can I trust the per-category counts as an audit record?
The counts tell you how many of each category were replaced and the total redacted, which is useful evidence. They do not list cell addresses, so they are a summary rather than a cell-by-cell log — pair them with your own record of which file and sheet you processed.
Privacy first
Every JAD Excel tool runs entirely in your browser using SheetJS and ExcelJS. Your spreadsheets, formulas, and data never leave your device — verified by zero outbound network requests during processing.