Browser-only. No server-side processing

GDPR pseudonymization. For CSV and Excel files

Replace direct identifiers (names, emails, IDs) with reversible tokens, producing a separate mapping file. Aligns with GDPR Article 4(5)'s pseudonymization definition. Runs in your browser.

Drop a file to anonymize

CSV, TSV, TXT or Excel. Runs in your browser, never uploaded.

Supported: .csv, .tsv, .txt, .xlsx, .xls

What GDPR Article 4(5) requires

GDPR defines pseudonymization as 'the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures.' Translation: replace identifiers with tokens, keep the mapping separate, protect the mapping.

Separate mapping: the anonymized file and the mapping never live in the same place
Reversible only with the key: anyone without the mapping cannot re-identify
Reduces (but doesn't eliminate) GDPR scope. Still personal data, but lower risk
Supports Article 32 (security of processing) by limiting blast radius of leaks

How our pseudonymization works

1
Identify direct PII
The detector flags emails, names, phones, DNIs/NIEs/NIFs, IBANs as direct identifiers.
2
Replace with tokens
EMAIL_0001, NAME_0023. Incremental, deterministic per column, preserving relationships.
3
Download mapping separately
Mapping is a JSON or CSV file the tool produces alongside the pseudonymized output. Store it in a separate system with restricted access.

Pseudonymization vs. anonymization (legally)

Pseudonymized data is still personal data under GDPR, Article 4(5) explicitly says so. Processing it still requires a lawful basis and DPIAs for high-risk processing. The benefit is reduced risk, not exit from scope.

Anonymized data (truly irreversible. Our Hash and Redact methods, when no mapping is kept) exits GDPR scope per Recital 26. The threshold for 'anonymous' is high: even combined with other reasonably-accessible data, no one should be able to re-identify. Pseudonymization is easier to achieve; true anonymization needs care.

When you need to re-identify

Use the reverse tool with the mapping file to translate tokens back. Pseudonymization is reversible by design. That's its defining feature.

Open the reverse tool →

Frequently asked questions

Is pseudonymization the same as anonymization?+

No. Pseudonymized data is still personal data (GDPR Art. 4(5)). The mapping that allows re-identification exists. Truly anonymous data has no such mapping and falls outside GDPR (Recital 26). Different legal regimes.

What makes a pseudonymization 'GDPR-compliant'?+

Three things: (1) direct identifiers replaced with tokens, (2) the mapping kept separately, (3) technical and organizational measures protecting the mapping. Our tool produces the first two; the third is your operational responsibility (where you store the mapping).

Does pseudonymization remove the need for consent or other lawful basis?+

No. Pseudonymized data is still personal data; you still need a lawful basis to process it. Pseudonymization reduces risk and supports Article 32 security, but doesn't substitute for compliance basics.

Where should I store the mapping file?+

In a different system from the pseudonymized data, with stricter access controls. A separate folder with the same access is NOT separate. Different vault, different ACL, audited access.