Redaction vs anonymisation vs pseudonymisation

Published 2026-07-29

These three words get used as synonyms in product copy and as distinct legal categories in regulation. The gap causes real mistakes: teams believe they have anonymised a dataset when they have pseudonymised it, then share it under rules that only apply to anonymous data.

Here is the distinction in plain terms, and what follows from it.

Redaction

Removing information from a document so it cannot be read.

Redaction is about the artefact. A redacted document has holes in it: black bars in a PDF where the underlying text objects have been deleted, or a text file where the characters are simply gone. The test is mechanical — is the information still recoverable from the file?

The classic failures are all failures of that test. A black rectangle drawn over live text in a PDF looks redacted and is not, because the text layer is still there and still selectable. Pixelated text in a screenshot has been publicly reversed. Deleted paragraphs survive in tracked changes and in file metadata.

Redaction is one-way by design. Done properly, nobody — including you — can recover what was removed. That makes it the right tool for publication and disclosure, and the wrong tool when you need the original back.

Pseudonymisation

Replacing identifying values with substitutes, keeping a separate key that reverses it.

This is what ScrubLocally does by default. “Sarah Chen” becomes [NAME_1]; the mapping from [NAME_1] back to Sarah Chen exists in your browser tab. The data is unreadable to anyone who does not have the mapping, and fully readable to anyone who does.

The GDPR treats this precisely. Recital 26 states that personal data which has been pseudonymised, and which could be attributed to a natural person by the use of additional information, should be considered information on an identifiable natural person — that is, still personal data. The EDPB’s Guidelines 01/2025 on pseudonymisation develop the point, introducing the idea of a “pseudonymisation domain” — the environment holding the keys and lookup tables — and expecting that environment to be protected by strong technical and organisational measures.

So pseudonymisation is a genuine safeguard, explicitly recognised and encouraged in the regulation. It is not an exit from the regulation. Your lawful basis, retention limits, data-subject rights and transfer rules all still apply.

For the specific job of pasting text into an AI tool, that is usually fine — because the thing you are trying to prevent is the third party receiving identifiable data, and it does not receive it. The key never travels with the text.

Anonymisation

Altering data so that no one can re-identify the individuals, by any means reasonably likely to be used.

This is a much higher bar, and it is a one-way door. If you can restore the original values, the data is not anonymous. If someone else could restore them using other information they hold or could obtain, it is not anonymous either. Truly anonymised data falls outside the GDPR entirely, which is exactly why the standard is strict.

The reason anonymisation is hard has little to do with names. It is the mosaic effect: identity reassembles from combinations. Age plus postcode plus gender narrows a population dramatically. “The regional sales manager who left in April” identifies one person to anyone inside the company. A rare diagnosis on a specific date identifies a patient to anyone with access to a second dataset.

HIPAA’s approach is instructive here. Its Safe Harbor method lists eighteen identifier types to remove — and then adds a second condition: the covered entity must have no actual knowledge that the remaining information could be used, alone or in combination, to identify someone. The alternative route, expert determination, exists because the list alone often is not enough. FERPA words it differently but lands in the same place: no reasonable basis to believe a student can still be identified.

Neither standard can be satisfied by a pattern matcher, because neither standard is about patterns.

Which one do you need?

Pasting text into an AI tool and wanting the answer back. Pseudonymisation. Placeholders, keep the mapping locally, restore afterwards. That is the round-trip workflow.

Sharing a document outside your organisation. Redaction. Use the block or delete styles, and check the output rather than the input — the redacted characters must not exist in what you send.

Publishing a dataset, or relying on the data no longer being personal data. Anonymisation, and that is a project, not a button. Expect to aggregate, generalise, suppress small cells and probably take advice. If you are relying on a legal category, the standard is legal, not technical.

Analysing your own data internally. Pseudonymisation is usually the right balance: you keep the ability to act on individual records, while limiting who can see identities.

Three practical rules

1. If it can be undone, it is not anonymous. However good the substitution looks. Anyone describing a reversible process as “anonymisation” is selling something.
2. The key is the crown jewel. With pseudonymised data, security shifts to protecting the mapping. That is why this tool keeps it in a browser tab and warns you when you download it: the key file undoes everything the redaction did.
3. Read what is left, not what was removed. Every framework converges on this. The identifiers are the easy half; the sentence that describes exactly one person is the half that machines cannot see.

Where the tool draws its lines

ScrubLocally offers four replacement styles, and the split is deliberate. Tokens and fake values are pseudonymisation: reversible, mapping in your tab. Blocks and delete are redaction: one-way, and the interface tells you the round trip is unavailable when you choose them.

None of the four is anonymisation, and the site does not claim otherwise anywhere. It is a first pass that removes identifiers accurately and shows you its work, so that the judgement you still have to make is a smaller one.