Is Hashed Data Anonymous Under UK GDPR? Hashing Emails and IDs the Right Way

"It's fine, we hash the email addresses." You'll hear this in almost every UK data-sharing discussion: uploading customer lists to ad platforms, sending analytics events to a third party, or keeping a "de-identified" copy of production for the data team. The UK GDPR changes made by the Data (Use and Access) Act 2025 have been coming into force in stages through 2026, so many teams are revisiting their data flows. One point hasn't changed: a hashed email address is still personal data. This guide explains why in technical terms, and what to do instead.

This is an engineering guide, not legal advice. For decisions about your own processing, read the ICO's guidance and talk to your data protection officer.

Anonymised vs pseudonymised: the distinction that matters

UK GDPR only stops applying to data that is truly anonymous, meaning no one can reasonably identify the person it relates to, by any means reasonably likely to be used. Pseudonymised data has had direct identifiers replaced, but it can still be linked back to a person with extra information. It remains personal data, and all the usual obligations still apply: a lawful basis, transparency, security, retention limits and data subject rights.

Pseudonymisation is still worth doing. The law treats it as a recognised security measure, and it lowers the harm if a dataset leaks. But it doesn't take the data outside UK GDPR. A plain hash of an email address is, at best, pseudonymisation.

Why a SHA-256 hash can be reversed in practice

SHA-256 is a one-way function: you can't mathematically run it backwards. You don't need to. It is also deterministic (the same input always gives the same output) and fast. Those two properties are enough to undo it for data like email addresses and phone numbers:

sha256("alice@example.com")
= ff8d9819fc0e12bf0d24892e45987e249a28dce836a85cad60e28eaaa8c6d976

Anyone holding a list of candidate emails, such as a marketing list, a breach dump or your own CRM export, can hash every candidate and look for matches. That's a dictionary attack, and it takes seconds. Phone numbers are even easier. A UK mobile number is 07 followed by nine digits, so there are only about one billion possibilities. A single modern GPU computes billions of SHA-256 hashes per second, so it can hash every UK mobile number in about a second and reverse any hashed number in your dataset.

Determinism causes a second problem: linkage. If two companies both hash emails with plain SHA-256, the same person gets the same hash in both datasets, and the datasets can be joined. Ad platforms' "customer match" features work this way on purpose. That's why uploading hashed emails counts as sharing personal data with that platform, and needs a lawful basis and a privacy notice that covers it.

You can check this yourself with the SHA-256 Generator: hash the same address twice and you get the same value both times. Change one character and you get a completely different value. Hashing is designed to behave this way. It's why hashing is good for integrity checks and poor for hiding low-entropy data. See our hashing vs encryption guide for the full picture.

Normalise before you hash, or matching fails

If you do hash identifiers for matching, normalise them first. Otherwise the same person produces different hashes and nothing matches:

sha256(" Alice@Example.com ")
= 727bc9b9f7ac8b9f4f6d2acf318d6ffbf4b807782f047d714309bea90f6424d2   ← no match

Trim whitespace and lowercase emails. Format phone numbers consistently: E.164 (+447…) is the usual choice, rather than a mix of 07…, +44 7… and 0044…. Check what the receiving platform expects. Most ad platforms specify their own normalisation rules and expect lowercase hex SHA-256.

Better options, depending on your goal

Internal pseudonyms: use a keyed hash (HMAC)

If you need a stable pseudonym, for example so analysts can count unique users without seeing email addresses, use HMAC-SHA256 with a secret key instead of a plain hash. Without the key, an attacker can't run the dictionary attack, because they can't compute candidate values:

import { createHmac } from 'node:crypto';

const PSEUDONYM_KEY = process.env.PSEUDONYM_KEY; // from a secrets manager, never in the dataset

function pseudonymise(email) {
  const normalised = email.trim().toLowerCase();
  return createHmac('sha256', PSEUDONYM_KEY).update(normalised).digest('hex');
}

Keep the key in a secrets manager, separate from the pseudonymised data, and restrict who can use it. That separation is what makes this pseudonymisation rather than simple obfuscation. The output is still personal data for anyone who holds the key. You can try keyed hashes with the HMAC Generator.

Reversible lookups: use tokenisation

If authorised staff sometimes need the original value back, for example support looking up a customer, replace the identifier with a random token (a UUID works well) and store the token-to-identity mapping in a separate, tightly controlled table. A random token has no mathematical link to the identity, so it can't be brute-forced. Our UUID guide explains why v4 UUIDs don't collide in practice.

Reporting and research: aggregate or generalise

Getting close to true anonymisation usually means removing the per-person row, not disguising it. Publish counts, not records. Suppress small groups: a table cell showing "3 people in postcode district X aged 90+" can identify individuals. Generalise, too: use the postcode district instead of the full postcode, and an age band instead of a date of birth. Whether the result is anonymous depends on context and on who receives it, which is why the ICO asks you to assess re-identification risk instead of relying on one technique.

Passwords: a different problem entirely

Password storage needs a deliberately slow algorithm such as Argon2id, scrypt or bcrypt, with a unique salt per user. Fast hashes like SHA-256 are the wrong tool for this. See how to create a strong password for the user side of the same problem.

A quick decision table

What the Data (Use and Access) Act changes, and what it doesn't

The Data (Use and Access) Act 2025 received Royal Assent in June 2025. It amends UK GDPR, the Data Protection Act 2018 and PECR, and its provisions are coming into force in phases. It changes areas such as recognised legitimate interests, automated decision-making, some cookie consent exemptions and the handling of subject access requests. It doesn't create a rule that hashed identifiers count as anonymous. The technical question stays the same: can someone reasonably get back to the person? For a plain hash of an email or phone number, the answer is usually yes.

Useful ToolzYard tools

Conclusion

Hashing hides the format of an identifier, not the identity behind it. Emails and phone numbers are too predictable for a fast, unkeyed hash to protect them, and deterministic hashes make it easy to join datasets. Treat hashed identifiers as personal data. Use HMAC with a separately held key for internal pseudonyms and random tokens where you need to reverse them, and only call data anonymous when there is no per-person row left to identify.