Pseudonymization, anonymization, and the words in between

Pseudonymization

Pseudonymization replaces an identifying value with a substitute — an alias such as PERSON_001 — while a separate mapping that can reverse the substitution continues to exist.

The GDPR defines it as processing personal data so it can no longer be attributed to a specific person without additional information, where that additional information is kept separately and protected. The decisive detail is that the link back still exists somewhere. That is what makes pseudonymized data useful for analysis, and also what keeps it inside the scope of data-protection law for whoever holds the mapping.

Data Alias pseudonymizes: it writes the mapping to a file you keep, and never holds a copy of it.

Source: GDPR, Article 4(5) — EUR-Lex

Anonymization

Anonymization removes the link between data and a person irreversibly, so that no one — including the party that performed it — can restore the original values.

It is a much higher bar than pseudonymization, and harder to reach than it sounds: data can often be re-identified by combining supposedly anonymous fields, so removing names alone does not achieve it. Because the link is gone for good, genuinely anonymized data falls outside the GDPR, which is precisely why regulators scrutinise claims that a dataset has reached that state.

Data Alias does not anonymize in this strict sense, and does not claim to. Its Remove rule discards a value permanently, but a file that keeps its aliases keeps its reversibility.

Source: EDPB draft Guidelines 02/2026 on Anonymisation

Pseudonymization vs. anonymization

Pseudonymization and anonymization differ in one respect that decides everything else: pseudonymization is reversible by whoever holds the mapping, and anonymization is reversible by no one.

Everyday usage treats the two words as synonyms; data-protection law does not. Pseudonymized data is still personal data. In September 2025 the Court of Justice of the European Union, in EDPS v SRB, addressed whether that holds even for a recipient who has no access to the mapping — an indication of how contested the boundary is. The safe working assumption for a team is that aliased data still carries obligations.

Source: EDPS v SRB (C-413/23 P) — CURIA

Deterministic aliasing

Deterministic aliasing means one source value always produces the same alias, so a name appearing in fifty rows becomes the same PERSON_001 in all fifty.

Its opposite — a fresh random alias each time — destroys exactly what makes a dataset worth analysing. Counting how many tickets a customer filed, joining two tables on a customer ID, or spotting that one account generates a fifth of your support load all depend on repeated values still matching after the transformation. Determinism is what preserves those relationships.

Data Alias is deterministic within a file and across a batch. To keep the same mapping across separate sessions, save it to an alias vault.

Reversible pseudonymization

Reversible pseudonymization is pseudonymization in which the mapping is deliberately retained, so an alias can be translated back to the value it replaced.

It matters when the point of the exercise is to get an answer back. If an AI tool reports that PERSON_014 is your highest-volume complainant, that finding is useless until you know who PERSON_014 is. Retaining the mapping is what closes that loop — and it is also the reason the resulting file is not anonymous, and should be handled accordingly.

Data Alias exports the mapping as a CSV you keep. Restore takes that file plus an AI answer or result file and swaps the aliases back, in the browser.

Masking

Masking hides part of a value while keeping its shape, so that some characters remain visible and the rest are replaced — turning +1 415 555 0198 into +1 *** *** 0198.

It is useful when the format itself carries meaning you want to keep, such as a country code or an email domain, and when partial visibility helps a human recognise a record without exposing it fully. Masking is not reversible from the masked value alone, and masked values do not reliably stay distinct from one another.

Data Alias offers Mask as a per-column rule, and suggests it for phone numbers.

Redaction

Redaction replaces a value with a fixed marker — a black bar, [REDACTED], a row of Xs — so that every redacted value looks identical to every other.

That uniformity is the point when the goal is disclosure control, and the problem when the goal is analysis. Once two different customers are both [REDACTED], nothing downstream can tell them apart, so counts, joins, and per-person patterns are gone. Redaction is the right tool for releasing a document and the wrong one for preparing a dataset.

Tokenization

Tokenization replaces a value with a token that carries no derivable relationship to the original, where the mapping between the two is held in a separate token vault.

It is the term the payments industry uses, and in practice it is pseudonymization with a particular architecture: the vault is usually a server-side service, which is what allows a token to be shared across many systems and reversed by whichever of them is authorised. The trade-off is that a service holding the vault necessarily receives the original values.

Data Alias has no vault service. The mapping is a file on your machine, which is the reason nothing has to be sent anywhere to create or reverse it.

Local-first processing

Local-first processing means a file is read, examined, and transformed by code running on the user's own device, and its contents are never transmitted to a server.

In a browser this means the work happens in JavaScript inside the open tab: the file is loaded through a file input, parsed in memory, and written back out as a download. No request carrying the file is made, which is a property you can confirm yourself by watching the network tab or by disconnecting from the network mid-task.

Local-first does not mean a Data Alias server sees nothing at all. It serves the page, and it can receive anonymous product events that never contain file data. What it never receives is the file.

Direct and indirect identifiers

A direct identifier names a person on its own — a full name, an email address, a national ID number — while an indirect identifier does so only in combination with others, such as a postcode, a job title, and a date of birth together.

The distinction explains why removing the obvious columns is not the end of the job. A support ticket that no longer carries a name can still describe an incident only one customer experienced. Automatic detection finds direct identifiers well and indirect ones poorly, which is why a human review step is not an optional extra.