k-Anonymity: Checking Leaks Without Giving Away Your Email

LEAKLENS EXPLAINER · CIVIC TECH GUIDE

# k-Anonymity: Checking Leaks Without Giving Away Your Email

The mathematics and privacy design of prefix-based checking systems that guarantee your credentials never leave your browser

Editorial note: This piece describes the k-anonymity model as implemented by HaveIBeenPwned (Pwned Passwords and the range-search API), the most widely deployed version of this design. Other leak-checking tools may implement the same idea differently, or not at all — always check a tool's own documentation before trusting it with anything sensitive.

The problem this solves

Every "check if your password/email has leaked" tool has an obvious trust problem: to check something, it looks like you have to hand it over. Type your real password into a form on some website you've never heard of, and you've just done the thing every security guide tells you not to do — except now you're doing it specifically to find out if your password is already compromised.

k-anonymity is the piece of math that makes this contradiction avoidable. It lets a server answer "have you seen this?" without ever being told what "this" is.

How it actually works, step by step

Take a password. Say it's a bad one — qwerty123.

The server never learns your password. It doesn't even learn your hash — only a 5-character prefix that, by design, matches hundreds of other hashes too.

Why 5 characters, specifically

This isn't arbitrary. SHA-1 hashes split cleanly into 16^5 — 1,048,576 — possible prefixes. HaveIBeenPwned creator Troy Hunt has explained the tradeoff directly: go one character shorter (4), and each server response gets 16 times larger, slowing things down for no privacy benefit. Go one character longer (6), and each response gets 16 times smaller — fewer possible matches sharing your prefix, which starts to erode the anonymity set that makes this whole thing work. Five is described as the sweet spot between response size and anonymity.

That "anonymity set" is the actual point. If your prefix is shared with, on average, several hundred other hashes, the server genuinely cannot tell which one is yours. That's what makes this k-anonymity rather than just "sending less data" — k, here, is roughly the size of that shared group.

Emails work the same way, with one twist

Checking an email address against a breach database uses the same range-query idea, but with a 6-character prefix instead of 5. That extra character matters: 16^6 is roughly 16.7 million possible prefixes, sixteen times more than the ~1,048,576 used for passwords. The reasoning is symmetrical to the password case: there are far more distinct email addresses in circulation than there are distinct passwords in common use, so a larger prefix space is needed to keep each response's anonymity set reasonably sized rather than either too large or too identifying.

What this design does not protect against

Worth being precise about the limits, because "your credentials never leave your browser" can sound like a stronger guarantee than it is:

• It protects the query, not the outcome. If the tool tells you "yes, this was in the Paidwork breach," that fact itself might be sensitive — but that's true of any breach-checking tool and isn't specific to k-anonymity.
• It depends on honest implementation. k-anonymity is a design pattern, not a certification. A tool that claims to use it but actually logs full inputs on the server side before hashing, or sends the full hash instead of a prefix, has broken the guarantee while still being able to say "we use k-anonymity" — technically true, practically meaningless. This is why checking a tool's actual network requests (via browser dev tools) or reviewing its source code, when available, is the only way to confirm the claim rather than just trust it.
• It doesn't anonymize you from the breach itself. k-anonymity protects your query to the checking service. It does nothing about the fact that your data may already be sitting in a leaked database somewhere else, fully attached to your name.

Why this matters for a tool like this one

Any leak-checking tool that asks for your email or password and doesn't explain — specifically, technically — what happens to that input before it reaches a server is asking for trust it hasn't earned. k-anonymity is one of the few designs in this space where you don't have to take that trust on faith. Here's how to check it yourself, on any tool that claims to use it:

If instead you see your actual email address or password sitting in the request body or URL, the tool isn't doing what it claims, regardless of what its marketing copy says. That's a rare property for a privacy claim to have — you can verify it yourself in under a minute — and it's why this model has become the standard the rest of the industry gets measured against.

• Troy Hunt — Understanding HIBP's Use of SHA-1 and k-Anonymity
• Have I Been Pwned — API Documentation
• Have I Been Pwned — Pwned Passwords
• Cloudflare — Validating Leaked Passwords with k-Anonymity