Subtitle: once you know where each method breaks, you know when a tool is worth it
Before handing a file to a client, or before asking ChatGPT to analyze it — cleaning personal data out of a spreadsheet is a recurring chore. There are several ways to do it, and all of them are valid. What differs is where each method breaks down. This post compares four, on practical terms.
Method 1: delete columns, find & replace (cost: zero)
Delete the name and phone columns outright, or swap specific values with Ctrl+H. For a one-off, small file where you know exactly which columns are sensitive, this is enough.
Where it breaks:
- Free text. Phone numbers and emails buried inside a "notes" or "memo" column slip straight past find & replace. In practice, this is where real leaks happen.
- Consistency. Replace the same person with different values in different rows and "this customer contacted us three times" disappears from the data. Fatal if the file is for analysis.
- Irreversibility. Deleted values don't come back — if you accidentally worked on the original, that's data loss.
Method 2: formulas and Power Query (semi-automated)
SUBSTITUTE, LEFT&REPT masking, or Power Query transformation steps encode your rules once. Worth it when files of the same shape arrive regularly.
Where it breaks: rule maintenance becomes its own job. A renamed column breaks the formulas; values inside free text still need regex-grade handling; and keeping alias consistency (same person → same code) in spreadsheet formulas means maintaining a VLOOKUP mapping sheet — which is itself another sensitive file to protect.
Method 3: free online scrubbers
Search for "remove PII from CSV" and you'll find plenty of free web tools. Detection quality has genuinely converged — by April 2026, OpenAI had released Privacy Filter, an open-source (Apache-2.0) PII masking model that runs in a browser, with OpenAI itself noting it is an aid, not a safety guarantee.
One thing to check before using any of them: does the file get uploaded to the service's server? If it does, the original you were trying to clean becomes a new exposure surface the moment you upload it — and depending on your jurisdiction, handing personal data to a third-party processor can carry legal obligations of its own. If a tool doesn't state where processing happens, open your browser's DevTools network tab and feed it a file; the traffic answers the question.
The other shared limit is one-shot processing. Most free tools scrub and stop — no mapping is kept, so there's no way to de-alias an AI answer back to real names, and next week's file starts from zero.
Method 4: local, in-browser pseudonymization
Detection and transformation run inside the browser; the file is never sent to a server. This approach bundles the failure points of methods 1–3 into a workflow: pattern detection inside free text, alias consistency (the same person is always PERSON_001), de-aliasing for AI responses, and an untouched original.
Data Alias, which we build, works this way (stating the interest upfront). Everything runs in-browser with no server transmission, and the verification steps are public. That said — whichever tool you use, automatic detection cannot catch every sensitive value, so never skip the pre-export review.
Which method, when
- One-off, small, clearly-located sensitive columns → method 1 is enough. Work on a copy.
- Same file shape, recurring → method 2 or 4; compare rule-maintenance cost against tool cost.
- Free-text columns (notes, call logs) in the mix → method 3 or 4, which have pattern detection. For 3, check where processing happens first.
- AI analysis whose results come back to real work → method 4, for alias consistency and de-aliasing.
- Whatever you choose → the final pre-export review is a human job.
The criteria for choosing aren't about tool polish. They're two questions: where does the original go, and does the data still work after cleaning?