Hashing Algorithm: What It Is, How It Works, and Why It Matters for Data Privacy

A hashing algorithm is a mathematical function that converts input data of any size into a fixed-length string of characters called a hash, digest or checksum. The same input always produces the same output, the process cannot practically be reversed, and even a tiny change to the input produces a completely different hash.

That short definition covers the technical core, but it leaves out the part that trips up developers, security teams and privacy officers every year: what hashing does and does not protect. A hashing algorithm can prove that a file was not tampered with, store passwords so that a stolen database is far less useful to an attacker, and let two systems compare data without exchanging it in the clear. It does not, on its own, make personal data anonymous. Regulators including the US Federal Trade Commission have said so repeatedly, and enforcement actions have followed companies that told customers otherwise.

This guide explains what a hashing algorithm is, how one works step by step, which algorithms are still safe, which are broken, how to store passwords correctly, and how hashing fits into data privacy law. It includes working code, comparison tables and five diagrams. If you are here for one thing, jump to the section on which hashing algorithm to use or the section on hashing and data privacy.

What Is a Hashing Algorithm?

A hashing algorithm, also called a hash function, takes an input (a word, a password, an email address, a document, a disk image) and runs it through a fixed series of mathematical operations to produce an output of a set length. That output is the hash value, and the length depends on the algorithm, not on the input. SHA-256 always produces 256 bits, usually written as 64 hexadecimal characters, whether the input is a single letter or a four-gigabyte video.

Three everyday analogies help. A hash is like a fingerprint: it identifies something without containing it. It is like a blender: you can turn ingredients into a smoothie, but you cannot turn the smoothie back into the original fruit. And it is like a tamper seal: if anything inside changes, the seal no longer matches.

Hashing in one sentence for each audience

• For developers: a hash function maps arbitrary-length data to a fixed-length value that you can compare, index or verify.
• For security teams: a cryptographic hash function is a one-way function used for integrity checks, signatures, password storage and message authentication.
• For privacy and legal teams: hashing is a security and pseudonymization technique, and the output can still be personal data if it can be linked back to a person.

The Properties of a Good Hashing Algorithm

Not every hash function is suitable for security. A cryptographic hashing algorithm is expected to have several properties, and an algorithm that loses any of them is considered broken for the purposes that depend on it.

Property	What it means	Why it matters
Deterministic	The same input always produces the same hash	Lets you verify data by recomputing and comparing
Fixed output length	Output size is constant regardless of input size	Makes storage and comparison predictable
Fast to compute	Hashing a message is efficient	Needed for integrity checks and signatures, but a drawback for password storage
Preimage resistance	Given a hash, it is infeasible to find any input that produces it	Prevents recovering the original data from the digest
Second preimage resistance	Given an input, it is infeasible to find a different input with the same hash	Prevents swapping a legitimate file for a malicious one
Collision resistance	It is infeasible to find any two different inputs with the same hash	Underpins digital signatures and certificates
Avalanche effect	A tiny change in input changes roughly half the output bits	Prevents guessing how close two inputs are

Collision resistance is the property that fails first in practice. Because a hash maps unlimited inputs to a limited number of outputs, collisions must exist mathematically. The security question is whether anyone can find one. For an n-bit hash, the generic birthday attack finds a collision in roughly two to the power of n divided by two operations, which is why a 256-bit hash is expected to offer about 128 bits of collision resistance and why shorter hashes are riskier.

A Hashing Algorithm Example: SHA-256 in Action

The easiest way to understand hashing is to run it. Here are real SHA-256 digests for a few short inputs.

Input	SHA-256 hash
hello	2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
Hello	185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
hello world	b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
Hello world	64ec88ca00b268e5ba1a35678a1b5316d212f4f366b2477232534a8aeca37f3c

Notice two things. Every output is 64 hexadecimal characters long, and capitalizing a single letter produces a hash that looks unrelated to the original. In the case of “hello” and “Hello,” 125 of the 256 output bits differ, which is almost exactly the 50 percent that a good hash function should produce. This is the avalanche effect.

You can reproduce these values yourself with any standard tool. On Linux or macOS, the command below prints the SHA-256 hash of the text you pipe in.

printf 'hello' | shasum -a 256
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  -

How Does a Hashing Algorithm Work?

The details differ by algorithm, but most widely used hash functions follow a similar pattern. The description below is simplified and uses the SHA-2 family as the example.

1. Preprocess the message. The algorithm pads the input so its length fits a required block size, and appends the original length so that messages of different lengths cannot be confused with one another.
2. Split into blocks. The padded message is divided into fixed-size blocks. SHA-256 works on 512-bit blocks.
3. Start from an initial state. The algorithm begins with a set of fixed constants, called the initialization vector, that define the starting internal state.
4. Mix each block repeatedly. For each block, a compression function runs many rounds of bitwise operations, rotations, shifts and modular additions. SHA-256 performs 64 rounds per block. Each round scrambles the state further, so every output bit depends on every input bit.
5. Chain the blocks together. The result of processing one block becomes the starting state for the next, which is why this design is called Merkle-Damgard construction.
6. Output the final state. After the last block, the internal state is the hash.

SHA-3 takes a different route. Based on the Keccak algorithm and standardized by NIST in FIPS 202, it uses a sponge construction that absorbs input into a large internal state and then squeezes out the digest. The different design matters because it is not vulnerable to some attacks that affect Merkle-Damgard hashes, such as length extension.

Cryptographic hashes versus non-cryptographic hashes

Not every hash function is meant to resist attackers. Hash tables in programming languages, database indexes and caches use fast non-cryptographic hashes such as MurmurHash, xxHash or SipHash, and error-detection codes such as CRC32 catch accidental corruption. These are optimized for speed and distribution, not for resisting someone who is trying to forge a collision. If an adversary is part of your threat model, use a cryptographic hash.

Types of Hashing Algorithms and How They Compare

Hashing algorithms fall into a few families, and they are built for different jobs. General-purpose cryptographic hashes such as SHA-256 are designed to be fast. Password hashing functions such as Argon2 are designed to be deliberately slow and memory-hungry. Keyed constructions such as HMAC add a secret so that only parties who hold the key can produce or verify the hash.

Algorithm	Output size	Status	Typical use
MD5	128 bits (32 hex characters)	Broken for security; practical collision attacks since 2004	Non-security checksums and legacy compatibility only
SHA-1	160 bits (40 hex characters)	Broken for collision resistance; first public collision in 2017; NIST plans to retire it by the end of 2030	Legacy systems being migrated; avoid in new designs
SHA-256	256 bits (64 hex characters)	Secure and widely deployed (SHA-2 family, FIPS 180-4)	Integrity checks, digital signatures, certificates, blockchain, HMAC
SHA-512	512 bits (128 hex characters)	Secure (SHA-2 family)	Integrity checks; often faster than SHA-256 on 64-bit CPUs
SHA-3 (for example SHA3-256)	224 to 512 bits	Secure; standardized in FIPS 202	Integrity and signatures where a different design from SHA-2 is wanted
BLAKE2 and BLAKE3	Up to 512 bits for BLAKE2; 256 bits by default for BLAKE3	Secure and very fast; not NIST-standardized	File hashing, deduplication, performance-sensitive integrity checks
PBKDF2	Configurable	Acceptable where FIPS compliance requires it, with a high iteration count	Password hashing and key derivation
bcrypt	184-bit hash in a 60-character string	Secure with an adequate cost factor; limited to 72 bytes of input	Password hashing
scrypt	Configurable	Secure; memory-hard	Password hashing and key derivation
Argon2id	Configurable	Secure; winner of the Password Hashing Competition and specified in RFC 9106	Password hashing (the preferred modern choice)

The SHA-2 family

SHA-2 is the workhorse of modern security. Designed by the US National Security Agency and published by NIST, it includes SHA-224, SHA-256, SHA-384, SHA-512 and two truncated variants of SHA-512. SHA-256 is used in TLS certificates, code signing, software update verification and the Bitcoin network. No practical attack on the full-strength function has been found, and SHA-256 remains the default recommendation for general integrity work.

SHA-3 and BLAKE

SHA-3 was selected through an open NIST competition and standardized in 2015. It is not a replacement for SHA-2, which remains secure, but a structurally different alternative that provides insurance in case a future attack breaks the Merkle-Damgard design. BLAKE2 and BLAKE3 are fast, modern hashes widely used in file tools and checksums, though they are not part of the US federal standards.

MD5 and SHA-1: why they are retired

MD5, designed by Ron Rivest in 1991, was shown to be vulnerable to practical collision attacks in 2004, and collisions can now be generated in seconds on ordinary hardware. SHA-1, published in 1995, held out longer, but in 2017 researchers at CWI Amsterdam and Google produced the first public SHA-1 collision, an attack they named SHAttered. Attackers have used MD5 collisions to forge certificates, and the weaknesses are why browsers and certificate authorities stopped trusting both. If you still see MD5 or SHA-1 in a security context, treat it as a finding to fix.

Hashing vs Encryption vs Encoding vs Tokenization

People often use these terms interchangeably, and the confusion causes real compliance mistakes. The differences matter for privacy law because they determine whether data is still personal data.

Technique	Reversible?	Needs a key?	Main purpose	Still personal data?
Hashing	No (one-way), but guessable inputs can be matched	No (unless keyed, as in HMAC)	Integrity, verification, pseudonymization	Usually yes if it relates to a person
Encryption	Yes, with the key	Yes	Confidentiality	Yes, while the key exists
Encoding (for example Base64)	Yes, by anyone	No	Format conversion, not security	Yes
Tokenization	Yes, through a protected lookup	A secured token vault	Replacing sensitive values with random stand-ins	Yes, for the party that can detokenize
Anonymization	Not by anyone, by design	No	Removing identifiability entirely	No, if truly effective

The key point is the last column. Of all of these techniques, only true anonymization takes data outside privacy law, and hashing is not anonymization. We return to that in detail below.

What Are Hashing Algorithms Used For?

Hashing underlies a surprising amount of everyday computing.

• Password storage. Systems store a salted, slow hash of each password rather than the password itself, so a stolen database does not hand attackers working credentials.
• File and software integrity. Publishers post a SHA-256 checksum next to a download so you can confirm the file was not corrupted or replaced.
• Digital signatures and certificates. A signature algorithm signs the hash of a document, not the document itself, which is why the hash must be collision resistant.
• Message authentication. HMAC combines a hash with a secret key to prove that a message came from someone who holds the key and was not altered.
• Blockchain and Merkle trees. Bitcoin hashes blocks with SHA-256, and Merkle trees let systems verify large datasets by comparing a single root hash.
• Version control. Git identifies every commit and file by a hash and is migrating from SHA-1 toward SHA-256.
• Deduplication and caching. Storage systems hash blocks to detect identical content without comparing it byte by byte.
• Data structures. Hash tables use non-cryptographic hashes to find data in constant time.
• Evidence and audit trails. Hashing a record at the time it is created lets anyone later prove that the record has not changed.
• Data matching. Companies hash identifiers such as email addresses so two parties can compare lists, which is where hashing collides with privacy law.

How to Hash Passwords Correctly

Password storage is where hashing algorithm choice matters most, and where the most common mistake is made: using a fast general-purpose hash such as SHA-256 or, worse, MD5. Speed is the enemy here. A single modern graphics card can compute billions of SHA-256 hashes per second, so an attacker who steals a table of fast password hashes can test enormous numbers of guesses offline.

Password hashing functions solve this by being intentionally expensive. They add a work factor, and in the case of memory-hard algorithms such as scrypt and Argon2, they require a large amount of memory per guess, which erodes the advantage of specialized hardware.

Salt, pepper and work factor

• Salt: a unique random value generated for each password and stored alongside the hash. It ensures that two users with the same password get different hashes and defeats precomputed rainbow tables.
• Pepper: an additional secret value kept outside the database, for example in a key management service, and mixed into the hash. If the database leaks but the pepper does not, the hashes are much harder to attack.
• Work factor: the tunable cost of the hash, such as iterations, memory size and parallelism. It should be raised over time as hardware improves.

Which password hashing algorithm should you choose?

1. Argon2id is the first choice for new systems. It combines resistance to GPU attacks with resistance to side-channel attacks, and it is specified in RFC 9106.
2. scrypt is a sound memory-hard alternative where Argon2id is not available.
3. bcrypt remains acceptable with an adequate cost factor, though it is not memory-hard and truncates input at 72 bytes.
4. PBKDF2 is the option when a FIPS-validated algorithm is required, and it needs a high iteration count.

The OWASP Password Storage Cheat Sheet publishes minimum parameters that are updated as hardware evolves. At the time of writing, it suggests Argon2id with at least 19 MiB of memory, two iterations and a parallelism of one, scrypt with a cost of 2 to the 17th power, bcrypt with a work factor of at least 10, and PBKDF2 with HMAC-SHA-256 at 600,000 iterations. Check the current version before you set parameters.

Code examples

The Python examples below have been tested. The first computes a SHA-256 hash for an integrity check. The second shows a keyed hash. The third and fourth store and verify passwords.

import hashlib, hmac

# 1. Plain SHA-256 (integrity checks, not passwords)
digest = hashlib.sha256(b"hello").hexdigest()

# 2. Keyed hash (HMAC) for message authentication or pseudonymization
key = b"secret-key-kept-outside-the-database"
tag = hmac.new(key, b"jane.doe@example.com", hashlib.sha256).hexdigest()

# Compare hashes in constant time to avoid timing attacks
hmac.compare_digest(tag, tag)

# 3. Password hashing with Argon2id (pip install argon2-cffi)
from argon2 import PasswordHasher
ph = PasswordHasher()
stored = ph.hash("correct horse battery staple")
ph.verify(stored, "correct horse battery staple")   # raises an error if wrong

# 4. Password hashing with bcrypt (pip install bcrypt)
import bcrypt
hashed = bcrypt.hashpw(b"correct horse battery staple", bcrypt.gensalt(rounds=12))
bcrypt.checkpw(b"correct horse battery staple", hashed)   # True

In Node.js, the equivalent of the first example is a single line.

require('crypto').createHash('sha256').update('hello').digest('hex');

How Attackers Beat Weak Hashing

Knowing how hashes get broken explains why the rules above exist.

• Brute force and dictionary attacks. The attacker hashes huge lists of likely passwords or identifiers and compares the results to the stolen hashes. Fast hashes make this cheap, and predictable inputs make it effective.
• Rainbow tables. These are precomputed lookup tables of hashes for common inputs. A unique salt per password makes them useless.
• Collision attacks. Against MD5 and SHA-1, attackers can craft two different files that share a hash, undermining signatures and integrity checks.
• Length extension attacks. With SHA-256 and SHA-512 used naively as a message authentication code (hash of secret followed by message), an attacker can append data without knowing the secret. HMAC and SHA-3 are not vulnerable in this way.
• Timing attacks. Comparing hashes with an ordinary equality check can leak information through response time, so use a constant-time comparison function.
• Low-entropy inputs. Hashing something with a small space of possible values, such as a phone number or a date of birth, does not protect it, because every possible value can be hashed and matched in moments. This one drives the privacy risk discussed next.

Which Hashing Algorithm Should You Use?

The right hashing algorithm depends on the job. The decision guide below covers the cases most teams face.

• Storing passwords: use Argon2id, or scrypt, bcrypt or PBKDF2 if your platform requires one of them. Never use plain SHA-256 or MD5.
• Verifying file or data integrity: use SHA-256 or SHA-512. SHA-3 and BLAKE3 are also sound choices.
• Authenticating messages or API requests: use HMAC with SHA-256 and a secret key, and compare results in constant time.
• Creating digital signatures or certificates: use SHA-256 or stronger, as required by the signature scheme.
• Pseudonymizing identifiers for analytics or matching: use a keyed hash such as HMAC-SHA-256, keep the key separate from the data, rotate it where possible, and treat the output as personal data.
• Non-security tasks such as hash tables and caches: use a fast non-cryptographic hash.
• Anything new that you are tempted to build with MD5 or SHA-1: do not.

Hashing and Data Privacy: Why a Hash Is Not Anonymous

Hashing is a valuable security tool, and it is also one of the most misunderstood privacy tools. The misunderstanding goes like this: if a company converts an email address, phone number or device ID into a hash before storing or sharing it, the result looks like random characters, so the data must be anonymous. Regulators do not accept that reasoning, and neither should your privacy program.

Why hashed data is still personal data

Under the GDPR, pseudonymization means processing personal data so that it can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected. The regulation is explicit that pseudonymized data is still personal data. Recital 26 says that data counts as anonymous only if the person is not identifiable by any means reasonably likely to be used, including by the controller or anyone else. Hashing an identifier is a pseudonymization technique, and the GDPR recognizes pseudonymization as a security safeguard in Article 32, not as an exit from the regulation.

The reason hashes fail the anonymity test is shown below. An email address is not a random secret. People can guess likely addresses, buy or steal lists of real ones and hash every candidate in seconds. If the result matches the hash you shared, the identity is recovered. And because the same email always produces the same hash, the hash works as a stable identifier that can follow a person across datasets and companies.

The risk is worse for low-entropy values. A phone number has a limited number of possible values, so every one of them can be hashed and tested on commodity hardware. Dates of birth, postal codes and short numeric IDs are in the same category.

What the FTC has said

The US Federal Trade Commission has addressed this directly. In a July 2024 technology blog post titled No, hashing still doesn’t make your data anonymous, FTC staff wrote that data is only anonymous when it can never be associated back to a person, and that hashes still create a unique signature that can track a person or device over time. The post revisited a 2012 blog post by then Chief Technologist Ed Felten making the same point, and it cited enforcement matters in which the Commission alleged that companies relied on hashing to describe data as anonymous or less sensitive, including cases involving Nomi Technologies and BetterHelp.

The practical lesson for compliance teams is about claims. A company that tells consumers it shares only “anonymous” or “non-identifiable” data while sending hashed emails or device identifiers to third parties can face deception allegations, even if the hashing itself was done correctly.

What US state privacy laws add

State laws such as the California Consumer Privacy Act define personal information broadly enough to include persistent unique identifiers, and a hashed email or device ID generally fits. To treat data as deidentified under the CCPA, a business must do more than hash it. It must take reasonable measures to ensure the data cannot be associated with a person, publicly commit to maintain and use it only in deidentified form and not attempt to re-identify it, and contractually obligate recipients to do the same. Hashing may be one control within that, but it is not the standard.

Hashed emails and advertising

The place where this plays out most often is advertising. Major ad platforms accept or require SHA-256 hashed email addresses and phone numbers for audience matching and conversion measurement, which has led many marketers to believe hashing makes the transfer privacy-safe. The hashing requirement is a formatting and matching convention. It does not remove the need for a lawful basis under the GDPR, valid consent where the ePrivacy rules require it, accurate disclosures, honoring opt-outs and Global Privacy Control signals under US state laws, and a vendor disclosure that matches reality.

This is also the reason hashed identifiers appear in privacy litigation. Plaintiffs and regulators look at what a tracking technology sends and to whom, and whether the visitor was told and agreed. A hashed email sent to an advertising platform before consent is still a transfer of an identifier.

When hashing genuinely helps privacy

Hashing is not useless for privacy. It helps when used for what it is good at, and with realistic expectations.

• Reducing breach impact. Salted, slow password hashes mean a stolen database is far less useful, which matters for security obligations under Article 32 of the GDPR and for breach risk assessment.
• Limiting internal access. Analysts can join datasets on a keyed hash without seeing raw emails, supporting data minimization.
• Keeping suppression lists. Businesses can store a keyed hash of an opted-out email so they do not contact the person again, while still treating the hash as personal data subject to retention limits.
• Proving integrity. A hash of a consent record or a scan report shows that it has not changed since it was created.

Use case	Is hashing appropriate?	Better practice
Storing user passwords	Yes, with a slow salted algorithm	Argon2id with a unique salt and a pepper kept outside the database
Sharing emails with an ad platform	Required by the platform, but not a privacy protection	Obtain valid consent, disclose the sharing, honor opt-outs, and treat the data as personal data
Opt-out or suppression list	Yes, with a keyed hash	HMAC with a protected key, minimal retention and clear documentation
Analytics user identifiers	Partly	Keyed hash with key rotation; avoid permanent, universal identifiers
Making a dataset anonymous	No	Aggregation, generalization or other anonymization techniques assessed against re-identification risk
Proving a record is unchanged	Yes	SHA-256 or stronger, with a trusted timestamp

Eight questions for your privacy program

1. Do any of our systems hash identifiers such as emails, phone numbers or device IDs, and where does the hashed output go?
2. Do our privacy notices call hashed data anonymous or non-identifiable? If so, can we defend that statement?
3. Is the hash salted or keyed, and is the key stored and controlled separately from the data?
4. Could someone with a list of likely inputs recover the originals by guessing?
5. Do we send hashed identifiers to advertising or analytics vendors, and is that disclosed and covered by consent or an opt-out?
6. Do we honor deletion and opt-out requests for hashed copies, including those held by vendors?
7. Do our password systems use Argon2id, scrypt, bcrypt or PBKDF2 with current parameters?
8. Can we show an auditor or regulator dated evidence of what our websites actually send?

Hashing as evidence

There is also a constructive compliance use. Privacy programs increasingly need to prove what a website did on a given day, such as what a consent banner showed and which trackers fired. A cryptographic hash of that record, taken at the time it is created, lets anyone later verify that it has not been altered. This is the principle behind tamper-evident logs and hash-verified evidence archives, and it is why SHA-256 verification appears in evidentiary reporting tools.

How Captain Compliance Helps

Hashing questions usually surface in privacy programs as visibility questions: what is our website sending, to whom and under what consent? Captain Compliance helps teams answer those questions with evidence.

• See what your site sends. Patrol scans for tracking tags, cookies and consent failures, and its detection coverage includes PII monitoring, so you can find identifiers going to third parties before a regulator or plaintiff does.
• Gate non-essential tracking behind consent. The consent management platform holds non-essential tags until a visitor opts in and honors Global Privacy Control signals, so hashed identifiers do not leave before consent.
• Document it. Patrol’s evidentiary output is SHA-256 verified, with dated scan records and screenshot archives that show what your consent interface looked like at the time.
• Keep disclosures accurate. Hosted privacy notices and vendor disclosures update as your technology changes, which helps keep what you say aligned with what your site does.
• Handle rights requests. The DSAR portal routes access, deletion and opt-out requests and leaves an auditable trail.

Want to know what your website sends today? Run a free privacy audit or book a demo and we will walk through the results with you. For definitions of related terms, see our privacy glossary.

Frequently Asked Questions

What is a hashing algorithm?

A hashing algorithm is a mathematical function that converts input of any size into a fixed-length string called a hash or digest. The same input always gives the same output, the output cannot practically be reversed, and a small change in the input produces a completely different hash.

What is the most secure hashing algorithm?

There is no single most secure algorithm for every purpose. For general integrity and signatures, SHA-256, SHA-512 and SHA-3 are considered secure. For passwords, Argon2id is the preferred choice. The right algorithm depends on the use case, and MD5 and SHA-1 should be avoided for security.

Can a hash be reversed or decrypted?

A cryptographic hash cannot be reversed mathematically, because it is a one-way function that discards information. However, attackers can recover the original input by guessing likely inputs, hashing them and comparing results. This works well against weak passwords and predictable data such as emails and phone numbers.

What is the difference between hashing and encryption?

Encryption is reversible with a key and is designed to keep data confidential. Hashing is one-way and is designed to verify integrity or compare values without revealing the original. You decrypt encrypted data to read it, but you never decrypt a hash.

Is MD5 still safe to use?

No. MD5 has had practical collision attacks since 2004 and should not be used for passwords, signatures or any security purpose. It can still serve as a simple checksum to detect accidental corruption, where no attacker is involved.

Which hashing algorithm should I use for passwords?

Use Argon2id, with scrypt, bcrypt or PBKDF2 as alternatives where required. These are slow by design and use a unique salt, which protects against brute force and rainbow table attacks. Do not use plain SHA-256 or MD5 for passwords.

What is a hash collision?

A collision occurs when two different inputs produce the same hash. Collisions must exist mathematically, but a secure algorithm makes them infeasible to find. When practical collisions are found, as with MD5 and SHA-1, the algorithm can no longer be trusted for signatures or integrity.

What is salting and why does it matter?

A salt is a unique random value added to each input before hashing. It ensures identical passwords produce different hashes and defeats precomputed rainbow tables, forcing an attacker to attack each hash separately.

Is hashed data considered personal data under the GDPR?

Generally yes. Hashing is a form of pseudonymization, and the GDPR treats pseudonymized data as personal data because the person can potentially be identified, for example by hashing a list of likely inputs and matching. Only data that is truly anonymous falls outside the regulation.

Does hashing an email address make it anonymous?

No. A hashed email is a stable identifier, and anyone with a list of likely addresses can hash them and look for matches. The FTC has said that hashing does not make data anonymous, and companies that describe hashed data as anonymous can face deception claims.

Sources and Further Reading

This guide draws on NIST publications FIPS 180-4 (the Secure Hash Standard) and FIPS 202 (SHA-3), RFC 9106 (Argon2), the OWASP Password Storage Cheat Sheet, the research behind the SHAttered SHA-1 collision, and the FTC technology blog posts on hashing cited above. Algorithm parameters and regulatory guidance change, so confirm current recommendations before implementing.

This article is general information and not legal or security advice. Consult qualified counsel and your security team about your specific systems and obligations.