Category: Tracking Technologies
Hashed Email Identifiers
Also known as: HEM, Hashed Email, Email Hash, Hashed Email (HEM)
Simply put
A hashed email identifier is a scrambled version of an email address, created by running the address through a mathematical function that turns it into a fixed-length string of characters. This process is designed to be one-way, so the code cannot be straightforwardly reversed back into the original email address. Marketers and advertising platforms often use these codes to recognise and match users across different services without directly sharing the plain email address.
Formal definition
A hashed email identifier is a cryptographic representation of an email address produced by applying a one-way hashing algorithm (commonly MD5, SHA-1, or SHA-256, yielding 32-, 40-, or 64-character outputs respectively) to the address. The hash acts as a pseudonymous identifier used for cross-context matching, audience linkage, and identity resolution in advertising and marketing contexts. It is important to note that hashing is not anonymisation: because a hash is deterministic and the input space of email addresses is enumerable, a hashed email can typically be re-identified or matched back to an individual, and in most EU and UK analyses it is therefore generally treated as personal data under the GDPR and as an online identifier that may trigger consent obligations under the ePrivacy Directive when stored on or read from a user's device. The specific legal treatment depends on facts and jurisdiction and is not resolved by the evidence here; whether processing hashed emails requires consent, and under which regime, should be assessed case by case.
Why it matters
Hashed email identifiers sit at the centre of a common misconception in digital marketing: that scrambling an email address through a hashing function removes it from the scope of data protection law. In most EU and UK analyses this is not the case. Because hashing is deterministic and the universe of possible email addresses is finite and enumerable, a hashed email can typically be matched back to an individual or re-identified. It is therefore generally treated as personal data under the GDPR rather than as anonymised data, and it may qualify as an online identifier that triggers obligations under the ePrivacy Directive when the value is stored on or read from a user's device. Treating a HEM as if it were anonymous can lead organisations to skip consent steps, transparency notices, and record-keeping that they may in fact be required to provide.
Who it's relevant to
Privacy officers and data protection professionals
Because hashed emails are generally treated as personal data rather than anonymised data in most EU and UK analyses, privacy teams should assess HEM processing against the full set of GDPR obligations, including lawful basis, transparency, and record-keeping. Do not assume that hashing alone removes an identifier from scope; the deterministic and enumerable nature of email hashes means re-identification is typically feasible.
Legal counsel and compliance teams
The legal treatment of a HEM depends on facts and jurisdiction and is not resolved by generic descriptions of the technology. Counsel should consider both regimes separately: whether storing or reading the hash on a user's device engages ePrivacy consent requirements, and whether the subsequent processing engages the GDPR. Requirements differ across the EU, the UK, and individual US states, so scope should be established before advising on a specific implementation.
Marketing and advertising operations
Marketers often rely on hashed emails for cross-context matching, audience linkage, and identity resolution across platforms without sharing plain-text addresses. This convenience should not be mistaken for a compliance shortcut, since the identifier may still require a lawful basis and, in many EU jurisdictions, prior consent. Coordinate with privacy and legal teams before deploying HEM-based matching.
Web developers and engineers
Those implementing hashing pipelines should understand that algorithm choice (MD5, SHA-1, SHA-256) affects output length but not the underlying re-identifiability of an email hash. Where a HEM is written to or read from a user's device, that action may itself trigger consent obligations under the ePrivacy Directive independently of downstream processing, so implementation details should be documented for compliance review.
Inside HEM
Hashing Function
A cryptographic process (such as SHA-256 or MD5) applied to an email address to produce a fixed-length string. Because the same input consistently produces the same output, hashed emails can serve as stable identifiers for matching a user across systems or parties.
Normalization Step
The practice of standardizing an email address before hashing (for example, lowercasing and trimming whitespace) so that the same address always yields the same hash. Without normalization, cosmetic variations would produce different identifiers and defeat matching.
Persistent Identifier Function
The role hashed emails play as a durable key that enables recognition of the same individual over time and across contexts, commonly used for audience matching, measurement, and advertising use cases.
Personal Data Characterization
In most EU and UK interpretations, a hashed email is generally treated as pseudonymized personal data rather than anonymized data, because it can be linked back to an individual and is often used specifically to single out or re-identify that person. This means the GDPR generally continues to apply.
Device Access and Consent Trigger
Where creating or reading a hashed email involves storing or accessing information on a user's device, or where the identifier is deployed via technologies such as pixels, tags, or SDKs, the ePrivacy rules on device access may apply in addition to the GDPR obligations governing the subsequent processing.
Common questions
Answers to the questions practitioners most commonly ask about HEM.
Does hashing an email address make it anonymous and therefore exempt from data protection law?
No. Hashing is a form of pseudonymization, not anonymization. A hashed email is typically still considered personal data in the EU and UK because the same input always produces the same output, allowing it to be used to single out, link, or match an individual across systems. Because the underlying value can often be re-derived (for example by hashing candidate email addresses and comparing) or matched against other datasets, hashed email identifiers generally remain within the scope of the GDPR and UK GDPR. Whether a given hashed identifier is personal data depends on the means reasonably likely to be used to link it back to a person, which is a fact-specific assessment.
If a user consented to cookies, does that cover the use of hashed email identifiers too?
Not necessarily. Consent obtained for one purpose does not automatically extend to others. Under EU and UK rules, consent must be specific and informed, so consent to store or read cookies does not by itself authorize collecting an email address, hashing it, and using the identifier for matching, enrichment, or advertising. In addition, the ePrivacy rules govern the storing of and access to information on a user's device, while the GDPR governs the subsequent processing of the resulting personal data; these are distinct requirements. Where hashed email identifiers are stored in or read from the device, or used for purposes such as targeted advertising, a separate and appropriately specific legal basis and, in many EU jurisdictions, prior consent may be required.
When in the data flow should we capture consent before generating a hashed email identifier?
As a general practice in the EU and UK, any consent that is required should be obtained before the email address is collected for the relevant purpose and before the identifier is generated or shared, because valid consent must be given prior to the processing it authorizes. Where the hashed identifier is stored on or read from the user's device, the ePrivacy consent requirement typically applies at that point, in addition to any GDPR legal basis for the processing itself. The precise sequencing depends on your specific data flow, the purposes involved, and the jurisdictions in which your users are located, so this should be mapped against your own facts rather than assumed.
How should hashed email identifiers be reflected in a consent management platform and in our records?
A CMP can help present the relevant purposes, capture the user's choice, and log the consent, but it does not by itself determine whether your use of hashed email identifiers is lawful; that requires legal judgment about purposes and legal bases. Where consent is the basis, records should generally allow you to demonstrate what the user was told and what they agreed to, consistent with accountability expectations. Because hashed email matching often occurs server-side or with third parties rather than purely through on-page tags, teams should confirm that the consent signal actually governs those downstream flows, which may fall outside what a typical tag-based CMP controls.
How do opt-out regimes such as certain US state laws affect our use of hashed email identifiers?
Requirements differ by jurisdiction and should not be assumed to be uniform. Several US state privacy laws, such as those in California, generally rely on an opt-out model rather than the opt-in consent typical of the EU and UK, and using hashed email identifiers to share data with third parties or for targeted advertising may fall within concepts like sale or sharing under those laws, triggering opt-out rights and, in some cases, recognition of signals such as Global Privacy Control. The specific obligations depend on the applicable state law, the nature of the processing, and the parties involved, so each regime should be assessed on its own terms.
What should we consider when sharing hashed email identifiers with advertising or analytics partners?
Sharing hashed email identifiers with third parties raises the same core questions as sharing any personal data: what is the purpose, what legal basis applies, what has the user been told and consented to, and what contractual and role assessments (for example whether parties act as controllers, joint controllers, or processors) are needed. The fact that the value is hashed does not remove these obligations, since it generally remains personal data capable of matching individuals. You should also consider transparency in your notices, any cross-border transfer implications, and whether the receiving party's use is consistent with the consent or other basis you rely on. These determinations are fact-specific and depend on the arrangement, so this entry does not resolve them for any particular case.
Common misconceptions
Hashing an email makes it anonymous, so data protection law no longer applies.
Hashing is generally regarded in the EU and UK as pseudonymization, not anonymization. Because a hashed email is designed to re-identify or match a specific individual, it typically remains personal data and the GDPR continues to apply. Whether any given hash could ever qualify as truly anonymous depends on facts not covered by this definition and is a contested, case-specific question.
Because the data is hashed, no consent or legal basis is needed to use it.
Using hashed emails for purposes such as advertising, audience matching, or analytics generally still requires a valid legal basis under the GDPR, and often prior consent in EU jurisdictions. Where the technology also involves accessing or storing information on the user's device, ePrivacy consent requirements may apply separately. Consent or a basis obtained for one purpose does not automatically cover others.
Hashed identifiers fall outside cookie consent rules because they are not cookies.
Similar tracking technologies such as pixels, SDKs, and local storage are generally subject to the same device-access and consent rules as cookies in the EU and UK, even though they are not literally cookies. The mechanism of identification does not by itself exempt hashed emails from these obligations.
Best practices
Treat hashed email identifiers as personal data by default in EU and UK contexts, and document a valid GDPR legal basis for each processing purpose rather than assuming hashing removes the obligation.
Where hashed emails are created, stored, or read via device access or technologies such as pixels, tags, or SDKs, assess ePrivacy consent requirements separately from the GDPR analysis, and obtain prior consent where it is required in the relevant jurisdiction.
Map the geographic scope of your audiences, since consent obligations differ between the EU, the UK, and individual US states, with EU regimes generally relying on opt-in and several US state laws relying on opt-out signals.
Normalize email addresses consistently before hashing and document the hashing and normalization method, so identifiers behave predictably and processing can be explained during audits or regulator inquiries.
Maintain records of the purposes, legal bases, and any consents associated with hashed email processing, and ensure your consent management platform or logging captures the relevant preferences where consent is the basis relied upon.
Seek case-specific legal review before relying on any claim that a hashed email is anonymous, and avoid presenting hashing alone as a guarantee of compliance.