Anonymize a CSV column by column

The salt is the whole argument

Start with the failure this is built to avoid. Somebody hashes a column of email addresses with plain SHA-256, ships the file, and calls it anonymous. It is not. Email addresses live in a small and highly guessable space. Anybody who suspects who your customers are takes their own list, hashes it with the same algorithm, and joins the two columns. No cryptography is broken. There is no brute force worth the name. It is a lookup table, and building one for a few million addresses costs a laptop about a minute. The same argument applies to phone numbers, national identifiers, postal codes and any other column drawn from a set an outsider can enumerate.

A salt closes that door. Before hashing, 128 bits from crypto.getRandomValues are prefixed to the value, so the digest depends on a secret the attacker does not have. The salt here is generated once per page load. It is never written into the output file, never sent over the network, and never saved to storage. When you close the tab it is gone. That means the mapping from token back to value cannot be reproduced afterwards by anybody, including us, because we never held it in the first place.

The algorithm underneath is SHA-256 through WebCrypto, the browser's own implementation. If a browser does not expose crypto.subtle, or has no cryptographic random source, the tool refuses to hash and says so. It does not quietly fall back to something weaker that produces a token which looks identical and is not. A wrong answer that looks right is the worst outcome available on a privacy page.

Tokens are truncated to sixteen hex characters by default, which is sixty four bits. That will not collide on any file a browser can open, and it keeps the output readable in a spreadsheet, which a sixty four character digest does not. You can raise it as far as the full digest if you would rather have the headroom.

Worked example: a repeated customer, and a join that survives

Here is orders.csv. Note that rows one and three are the same person:

order_id,customer_email,full_name,mobile_phone,zip,order_total,signup_date
A-9001,rita.okafor@northwind.example,Rita Okafor,+44 7700 900431,SW1A 1AA,148,2024-03-11
A-9002,dan.mercer@northwind.example,Dan Mercer,+1 415 555 0132,94043,2310,2024-03-12
A-9003,rita.okafor@northwind.example,Rita Okafor,+44 7700 900431,SW1A 1AA,37,2024-04-02

Run it with the automatic plan and the output is this:

order_id,customer_email,full_name,mobile_phone,zip,order_total,signup_date
74ddd07aa4a179b7,134bccd0eaaa3c30,Nadia Ramirez,+*************1,SW1A ***,148,2024-03
a8587b3c4baf7b5d,6ea8dc30849c37a3,Karan Khan,+*************2,940**,2310,2024-03
e21c420b048e0172,134bccd0eaaa3c30,Nadia Ramirez,+*************1,SW1A ***,37,2024-04

Look at the email column. Rows one and three carry 134bccd0eaaa3c30, the identical token, because the same input hashed with the same session salt gives the same digest and distinct values are hashed once and reused. That is the join key doing its job: a group-by on this column still tells you Rita placed two orders totaling 185. The name column agrees, because fake values are drawn deterministically from the value too, so one person keeps one invented name throughout the file. Meanwhile order_id gets three different tokens, correctly, because those were three different orders.

And the summary that comes with it:

3 rows, 7 columns
6 columns changed, 1 kept
order_id → hash (from the column name), 3 cells changed
customer_email → hash (from the column name), 3 cells changed
full_name → fake (from the column name), 3 cells changed
mobile_phone → mask (from the column name), 3 cells changed
zip → generalize (from the column name), 3 cells changed
order_total → keep (from the column name), 0 cells changed
signup_date → generalize (from the column name), 3 cells changed

Warning: 1 column was left exactly as it is: order_total.
Check none of them identifies anybody on its own or in
combination with the others.

The per-column change count is there so you can catch a strategy that did nothing. A masked column reporting zero changed cells means it was empty, and an empty column that you believed was being masked is exactly the kind of thing worth knowing before the file leaves your machine. The (from the column name) tag marks a guess rather than an instruction from you, which is your cue to check it.

Notice also what the postal codes did. SW1A 1AA became SW1A ***, keeping the UK outward code, and 94043 became 940**, keeping the US sectional center. Those are the standard de-identification cuts and they keep the column useful for regional analysis. The dates lost their day and kept their month. Any numeric column that you route to generalize goes into a bucket one order of magnitude below the value and never narrower than ten, so 148 becomes 100-199 and 37 becomes 30-39. A bucket of width one is not a generalization, it is the original value with a dash in it.

What the free anonymizers usually do instead

This matters because the words on the button are the same and the thing underneath is not. The common free CSV anonymizer offers hash, mask and fake, exactly as this one does. Here is what those three mean over there.

Its hash is djb2: a thirty two bit non-cryptographic checksum from 1991, designed for hash tables, emitted as tok_<base36>. It is not a cryptographic hash and it was never meant to be one. Over a domain the size of an email list it is brute-forceable in seconds on a laptop, because thirty two bits is about four billion possibilities and there is no salt to widen the search. It also collides: at a few tens of thousands of distinct values you should expect two different customers to receive the same token, which quietly merges two people into one row in every downstream count.

Its mask leaves the email domain in the clear, so j***@acme-widgets.com is the output. The name is gone and the employer is not, which on an HR export or a customer list of any specificity is most of the way back to a person.

Its fake pools hold twenty first names, sixteen surnames and ten cities. On a five thousand row file every first name appears around two hundred and fifty times, which stops being an anonymized data set and starts being a data set about twenty people. The pools here are 264 first names, 270 surnames and 274 cities, which is more than seventy one thousand name combinations, and the phone numbers come from reserved fiction ranges so a generated number can never ring anybody.

None of this makes that tool useless for a screenshot. It makes the word hash on its interface wrong, and a person reading that word makes decisions about real people's data based on it. That is the whole reason this page spends four paragraphs on a salt.

Practical notes

• The plan comes from headers, then from you. The automatic plan reads each header with the same role detector the PII scanner uses. Run once, copy the printed plan, edit it, paste it into the custom box.
• Typos in a plan are reported, never ignored. An unknown column or an unknown strategy comes back as a warning naming the dropped rule, because a silently ignored rule leaves a column in the clear.
• Blank cells stay blank. No strategy invents a value where there was none, so missingness is preserved and a hashed empty string never appears.
• Distinct values are hashed once. A column of fifty thousand rows with three hundred distinct values does three hundred digests, which is both faster and the reason tokens repeat.
• The fake seed is separate from the salt. Fake values are reproducible from a seed you control, so a demo file can be regenerated exactly. Hashes are not, because the salt is random by design. Do not confuse the two.
• Check the output before you send it. Open the result in the viewer, or run it back through the scanner. A second pass costs thirty seconds and catches the column you forgot.