How Password Leak Checkers Work Without Exposing Your Password.

It sounds paradoxical: a service that checks whether your password has been compromised without ever knowing your password. But that's exactly what tools like Have I Been Pwned's password checker do, using a clever cryptographic technique called k-anonymity.

The k-Anonymity Approach

When you check a password, your browser hashes it using SHA-1 and sends only the first 5 characters of the hash to the API. The API returns all known breached password hashes that start with those same 5 characters (typically 500-600 hashes). Your browser then checks locally whether your full hash appears in that list.

Why This Matters

At no point does your password or its full hash leave your device. The server never has enough information to reconstruct your password. This is privacy-preserving security at its finest — and it's why you can trust these tools.

The cryptography behind safe checking

The most widely used technique behind password leak checkers is k-anonymity, popularized by Troy Hunt's Have I Been Pwned API. When you type a password into a compatible client, the password is hashed locally with SHA-1, and only the first five characters of the hash are sent to the server. The server returns every hash in its database that begins with those five characters. The client then compares the rest locally. Your full hash, let alone your password, never leaves your device.

The trick is that five characters of a SHA-1 hash represent roughly one million possible prefixes, and the typical response contains 300 to 800 matching hashes. That set is large enough to make the server statistically uncertain which one you were actually checking. Even if the server is malicious and logs every query it receives, it cannot recover your specific password without exhausting an enormous compute budget against an already-hashed value with no clear target to guess at.

Browser based password monitoring inside Chrome, Firefox, and Safari uses a similar but more advanced cryptographic protocol called private set intersection. Apple, Google, and Mozilla each implement variants that keep both the password and the breach database technically separate from each other during the comparison. The math is heavier than k-anonymity, but the privacy guarantee is similar. The browser learns whether your password is in a breach without revealing which password was checked.

A red flag is any leak checker that asks for your password to be typed without explaining its protocol. Some sketchy sites simply send the plaintext password over HTTPS and check it server side. The data never appears in a breach dump, but the operators now have a fresh record of working credentials sent to them voluntarily. A site with no documentation, no API description, and no link to a credible breach corpus should not be trusted with any of your real passwords.

Built in tools are the safest path for casual users. Bitwarden, 1Password, and Dashlane all integrate breach checking with the same k-anonymity model on the backend. Apple Passwords and Chrome's password checkup do the same. You do not need to copy your secrets into a third party form. Let the tool you already use handle the lookup, and reserve manual checks on Have I Been Pwned for email addresses only, never for full passwords typed into a browser form.

How Have I Been Pwned set the standard

Troy Hunt launched Have I Been Pwned in December 2013 after the Adobe breach exposed 153 million records. For the first three years the site only checked email addresses, but in August 2017 Hunt released Pwned Passwords, a downloadable list of half a billion SHA-1 hashes pulled from real breaches. The original v1 API required sending the full hash, which Hunt himself flagged as a problem. Cloudflare engineer Junade Ali proposed k-anonymity in early 2018, and v2 launched in February that year. Today the dataset sits north of 850 million unique password hashes, all served free through the same prefix-based API.

What made the model durable was that it was boring on purpose. There is no account, no telemetry beyond standard Cloudflare logs, and no business model that depends on knowing what you searched. Bitwarden, 1Password, Firefox Monitor, and Apple's iCloud Keychain all plugged into the same API or shipped their own local copy of the hash list. When you see a green checkmark next to a password inside 1Password's Watchtower, the math behind it is almost always the same SHA-1 prefix lookup that Cloudflare and Have I Been Pwned standardized seven years ago.

Where browsers handle this without you noticing

Chrome's Password Checkup, which Google rolled into the browser in October 2019, uses a slightly different protocol called private set intersection. Your saved passwords get hashed locally, blinded with a per-user key, then compared against a server-side encrypted set of breached credentials. Google never sees the underlying password and you never download the full breach corpus. The cryptography paper from Thomas, Pullman, and others at Google describes the scheme in detail, and the same approach now runs inside Safari's iCloud Keychain monitoring on iOS 14 and later. Firefox Lockwise, before its sunset, used the Have I Been Pwned API directly.

The user-visible part is intentionally quiet. On a fresh sign-in to Chrome with a synced password manager, the browser may flag a leaked credential within a minute and surface the warning inside chrome://settings/passwords/check. There is no popup, no nag, just a yellow dot. That restraint matters because heavy-handed warnings train people to dismiss them. Safari's behavior, layered into the Passwords app that Apple split out of Settings in iOS 18, follows the same low-friction pattern. If a user only ever learns about leak checking through a browser they already trust, the protocol working invisibly is the win.

Why salting and pepper do not help here

Anyone who has read about password storage knows that hashing without a salt is a bad idea. So why does Have I Been Pwned ship a plain SHA-1 corpus of breached passwords? Because the threat model is different. The site is not storing your password to authenticate you later, it is checking whether the exact string you typed has ever appeared in any breach anywhere. Adding a salt would make every hash unique to each user and break the whole comparison. The compromise is that the corpus only contains passwords that were already public, which is why exposing them again does not create new harm.

This is also why a leak checker is not a substitute for proper storage on the server side. When you sign up for a new service, that site should be running Argon2id or bcrypt with a unique salt per user, ideally with a server-side pepper too. Auth0, Supabase, and Clerk all default to Argon2 or bcrypt in 2026. The leak checker only protects you against password reuse after a breach somewhere else has already happened. Both layers are needed, and confusing them is a common mistake even experienced developers make when they first see the Pwned Passwords list.

What the API request actually looks like

If you crack open the network tab on haveibeenpwned.com when checking a password, you see a single GET request to api.pwnedpasswords.com/range/ followed by five hex characters. That is the first five characters of the SHA-1 hash of the password you typed. The server responds with a list of every full hash suffix that starts with those five characters, along with the number of times each one has appeared in known breaches. Your browser does the final comparison locally. The whole round trip is under 50 kilobytes for most prefixes and finishes in under 200 milliseconds on a typical connection.

The elegance is that no single party ever sees both halves. Cloudflare, which fronts the API, only sees the five-character prefix, which maps to roughly 16 million possible passwords. Even a determined attacker watching the wire learns very little. The same prefix can correspond to passwords that have nothing to do with each other, and the response set is the same for every user who queries it. This is what cryptographers mean by k-anonymity. You are hidden inside a crowd of at least a few hundred other candidate plaintexts, and that crowd is what makes the lookup safe.

What a leak checker cannot tell you

A green checkmark means the exact string you typed is not in any known breach corpus. It does not mean the password is strong, it does not mean you are not being phished, and it does not mean the site you are using stores passwords safely. A 12-character password like CorrectHorseBattery42 may be absent from every leak dataset and still fall to a targeted brute-force if the attacker has the password hash. The checker has no opinion on entropy, on whether you reused the password across two accounts, or on whether your email provider supports modern phishing-resistant MFA like passkeys or YubiKeys.

There is also a long tail of breaches that never make it into the public corpus. Credentials traded on closed Telegram channels or sold to a single buyer on Russian Market may never appear in Have I Been Pwned, even years after the original theft. The 2024 Snowflake-related breaches, which hit Ticketmaster and AT&T, took months to fully ingest. So a clean checker result is good news but not a guarantee. Pair it with a password manager generating unique 20-plus character strings, MFA on every important account, and you have closed almost all of the gap a checker leaves open.

How to build leak checking into your own product

If you run an authentication system in 2026, blocking the worst leaked passwords at signup costs you almost nothing. NIST SP 800-63B, revised in 2024, explicitly recommends checking proposed passwords against a list of commonly compromised values. The Have I Been Pwned Pwned Passwords v8 download is around 13 gigabytes uncompressed and ships as an ordered list of SHA-1 hashes, easy to load into Redis or even SQLite. Cloudflare offers a free hosted API with no rate limits for the prefix endpoint. Either way, the engineering lift is a few hours, and the user-experience win is preventing accounts that were doomed from day one.

The implementation detail that catches most teams is when to check. Doing it at signup and password change is mandatory. Doing it on every login is overkill and adds latency. A reasonable middle ground is to run a background check against your stored credentials after each new breach is published, and to nudge affected users at their next sign-in. Have I Been Pwned offers a free callback API for exactly this. Done right, the user never knows the check happened until the one moment they need to. That is the whole point of leak checking, and it is why the math behind it has stayed boring on purpose.