Data anonymization techniques explained with examples

The main data anonymization techniques are masking, generalization, aggregation, noise, swapping, tokenization, pseudonymization and hashing, plus two ways of measuring the result: k-anonymity and differential privacy. None of them is enough on its own. European regulators say every technique leaves some risk of re-identification, and the result counts as anonymous only when nobody can reasonably work out who a record is about.

Four small stacks of index cards in a row on a cream desk: one with navy tabs over the lines, one with lines blurred to grey bars, one with corners cut off, one blank, beside a navy pencil, a plant and a mug.

The test every technique is measured against

Under the GDPR and the UK GDPR, anonymous information is outside data protection law, and personal data is inside it. Recital 26 draws the line: you take into account all the means "reasonably likely to be used", such as singling out, to identify someone directly or indirectly. The same recital says that pseudonymized data that can be attributed to a person with additional information is still information about an identifiable person.

The EU data protection regulators of the time, the Article 29 Working Party, turned this into three questions in their Opinion 05/2014 on Anonymisation Techniques (WP216). Can someone still single out one person? Link two records about the same person? Infer something about a person? The opinion concludes that each technique it reviews fails at least one of these questions in some situations, which is why techniques are combined. The UK regulator's anonymisation and pseudonymisation guidance, published on 28 March 2025, takes the same risk-based view.

If you need the difference between anonymization, pseudonymization and redaction first, start with which one you need for AI. This article is about the individual techniques.

The sample record

All examples below start from the same made-up record from an HR file:

Anna Kowalski, born 12.03.1989 (37), 14 Elm Street, Leeds,
anna.kowalski@example.com, staff nurse, 12 days of sick leave

Techniques that remove or blur values

Masking and suppression

Masking hides part of a value; suppression deletes the value, the column or the whole record.

A***** K*******, born **.**.1989, [address removed], staff nurse

It protects against direct identification. It breaks anything that needs the removed value, and it is not reversible from the output. What remains can still point to Anna: a staff nurse born in 1989 is not hard to find in a small ward. Masking alone rarely makes data anonymous.

Generalization

Generalization replaces a precise value with a broader one.

age 37 → 30-39; 14 Elm Street, Leeds → Leeds; staff nurse → healthcare worker

It protects against singling out by making many people look alike. It breaks precision: you can no longer say who is older. It is not reversible. Whether the result is anonymous depends on how many people share each combination, which is what k-anonymity measures (see below).

Aggregation

Aggregation publishes totals or averages instead of individual rows.

Ward 4, 2025: 23 nurses, average sick leave 9.4 days

It protects individuals as long as each group is large. It breaks every question about a single person. With a group of one or two, the average gives the individual's figure away, so small cells are usually suppressed.

Noise (perturbation)

Noise changes values slightly at random.

age 37 → 39; sick leave 12 days → 10 days

It keeps statistics roughly correct while making each value unreliable. It breaks exact figures. WP216 warns that unless the noise outweighs the information, noise is not a standalone anonymization method: an outlier, such as the only person with 90 days of leave, stays recognizable.

Swapping (permutation)

Swapping exchanges values between records, so each column keeps its totals but rows no longer belong to one person.

Anna's 12 days of leave ↔ another nurse's 3 days

It protects against linking a value to a person. It breaks the relationships between columns, and WP216 shows it fails when the swapped values are tied to other columns: a manager's salary moved onto a junior job title stands out.

Techniques that replace identifiers

Tokenization

Tokenization replaces an identifier with a random token and keeps the link in a separate, protected table.

anna.kowalski@example.com → TKN-8F3K2Q

The ICO notes that a random token has no mathematical relation to the original, so the token alone reveals nothing. It is reversible by whoever holds the table, and that is why the result is still personal data for them.

Pseudonymization with consistent placeholders

Each person, company or address gets a readable placeholder, and the same value always gets the same one.

Person_1, born [Date_1], [Address_1], staff nurse.
Person_1 asked Person_2 to approve the leave.

It hides direct identifiers and keeps who-did-what readable, which matters for text. The logic of the document survives. It is reversible with the mapping, and under Recital 26 it remains personal data. The key-holder question in detail is in our article on whether pseudonymized data is still personal data.

Hashing

Hashing runs a value through a one-way function and keeps the output.

anna.kowalski@example.com → 3f9a…c71e (SHA-256)

It looks irreversible, but for names and email addresses it often is not. Anyone with a list of likely values can hash each one and compare: there are only so many staff names or company addresses. WP216 makes this point about known input ranges, and the ICO advises against hashing without a salt, pepper or key, and against outdated algorithms such as MD5 and SHA-1, because they are open to brute-force attacks. A keyed hash is pseudonymization; a plain hash of an email is barely that.

k-anonymity and differential privacy

These are not ways to change a value. They are ways to check, or guarantee, how well a whole dataset is protected.

k-anonymity means every combination of identifying attributes (age band, town, job) is shared by at least k records. With k = 5, Anna hides among at least five people who look the same. It does not stop inference: if all five healthcare workers aged 30 to 39 in Leeds had more than ten days of leave, you learn that about Anna. l-diversity adds a rule that each group must contain at least l different values of the sensitive attribute.

Differential privacy works on answers rather than rows. Noise is added to each published statistic, calibrated so that the answer barely changes whether or not any one person is in the data. The protection is set by a parameter, and stronger protection means less accurate figures. The US Census Bureau used it for the 2020 Census data products, apart from the state totals used for apportionment. It suits statistics; it does nothing for a document someone needs to read.

For tables, tools do this measuring for you. ARX, a free, open-source desktop tool and Java library (Apache 2.0 license, version 3.9.2 as of October 2026), applies generalization, suppression and microaggregation to structured data and checks the result against k-anonymity, l-diversity, t-closeness and differential privacy. It also estimates the remaining re-identification risk. It is built for datasets such as CSV files, Excel sheets and database tables, not for contracts or letters.

All techniques side by side

Technique	Protects against	Breaks	Reversible	Still personal data under the GDPR
Masking, suppression	Direct identification	Anything that needed the value	No	Usually, if other details remain
Generalization	Singling out	Precision	No	Depends on group sizes
Aggregation	Singling out, linking	All per-person questions	No	Often not, if groups are large
Noise	Exact values	Exact figures	No	Usually, on its own
Swapping	Linking a value to a person	Relationships between columns	No	Usually, on its own
Tokenization	Direct identification	Little	Yes, with the table	Yes
Pseudonymization (placeholders)	Direct identification	Little; text stays readable	Yes, with the mapping	Yes
Hashing	Casual reading	Little	Often by guessing, without a key	Yes
k-anonymity, l-diversity	Singling out; inference (l)	Precision, some records	No	Depends on k, l and context
Differential privacy	Learning about one person from statistics	Exact figures, all per-person use	No	Depends on the parameters

Most rows say "depends" because whether a dataset is anonymous is decided for the whole dataset in its context, not per technique. For anything you plan to publish or share as anonymous, ask your DPO or a data protection lawyer.

Which techniques fit documents you give to AI

A dataset for statistics and a document for an AI chatbot need opposite things. Statistics need many rows and no individuals; aggregation, generalization, k-anonymity and differential privacy are built for that. A contract, an email thread or a grievance letter is about specific people, and the AI has to follow them.

For documents, three techniques do most of the work:

Pseudonymization with consistent placeholders for names, companies, addresses, emails and ID numbers. Person_1 stays Person_1 across the whole text, so the AI can tell who wrote what and who owes whom. Black bars or a single "[REDACTED]" erase that; see why placeholders work better.
Generalization for dates and places the question does not need exactly: "March 2025" instead of a day, "a city in the north of England" instead of a street.
Suppression for whatever the question does not need at all, such as a health detail in a document you are only asking about notice periods.

Noise, swapping and differential privacy have no place here: changing facts in a document makes the AI's answer wrong. Hashing turns names into strings nobody, including the AI, can read in context.

The result is pseudonymized, so the data protection rules still apply to you. What changes is what leaves your PC. If you are choosing software for this, our checklist of what to look for in a pseudonymization tool covers where the data goes and how the names come back.

Frequently asked questions

What is the most effective data anonymization technique?

There is no single one. WP216 found that every technique it reviewed falls short of at least one of the three tests in some situations. For statistical datasets, generalization and suppression measured with k-anonymity, or differential privacy, give the strongest results. For documents an AI must read, pseudonymization with generalization of dates and places is the practical choice, and it is not anonymization.

Is hashing an email address enough to anonymize it?

No. Email addresses follow predictable patterns, so an attacker can hash a list of likely addresses and match the results. A keyed hash or a random token is safer, and both are still pseudonymization, not anonymization.

What are data anonymization tools for tables?

ARX is a free, open-source example: you load a CSV, Excel file or database table, set rules for generalization and suppression, choose a privacy model such as k-anonymity, and it reports the remaining risk. Tools of this kind work on columns and rows, not on running text.

Does anonymized data fall under the GDPR?

Truly anonymous data does not, according to Recital 26. Pseudonymized data does. The hard part is proving that nobody can reasonably re-identify the data, which is why regulators treat anonymization as a risk assessment rather than a single step.

ClientSafe pseudonymizes documents on your PC: it replaces names, companies, addresses, phone numbers, email addresses, account and ID numbers and dates of birth with placeholders such as Person_1, and keeps the same placeholder for the same name across every document in a case. Detection is not perfect, so review the list before you copy.