Password Leak Checker: How a Pwned Password Lookup Works Without Sending Your Password

There is a question every login screen quietly raises and almost nobody answers honestly: has this exact password already shown up in a data breach somewhere? Not "is it strong" in the abstract, but "is this specific string already sitting in a file that attackers download and feed into their tools." Those are different questions, and the second one is the one that gets accounts taken over.

A password leak checker answers it. You type a password, and it tells you whether that password has appeared in the compiled corpus of breach dumps, plus how many times. The catch that stops most people from using one is obvious: typing your real password into a website to ask if it has leaked feels like the dumbest possible move. The good news is that a properly built checker never actually sends your password anywhere. Here is how that works, and what to do with the answer.

The range query: your password never leaves the device

The technique is called k-anonymity, and the mechanics are worth understanding because they are the entire reason this is safe to use.

When you click Check, the Password Leak Checker hashes your password to SHA-1 entirely inside your browser, using the Web Crypto API (crypto.subtle.digest) — the same cryptographic primitive that powers HTTPS. That produces a 40-character hexadecimal hash. The tool then takes only the first 5 hex characters of that hash and sends just those 5 characters to the public HaveIBeenPwned range API. The server replies with a list of around 400 to 800 hash suffixes that all share that 5-character prefix. Your browser then compares the remaining 35 characters of your hash against that returned list, locally. The match check happens on your machine.

Read that again, because it is the load-bearing detail: the full password never leaves your device, the full hash never leaves your device, and the final comparison never leaves your device. The server sees five hex characters. With 16^5 ≈ one million possible prefixes spread across 800M+ leaked hashes, any prefix you send is shared by roughly 800 unrelated hashes. Even if the server logged every request forever, the most it could conclude is "this visitor asked about one of about 800 hashes" — not which one, and certainly not the password behind it. That is what 1Password, LastPass, and Firefox Monitor do for the same job. You can confirm it yourself: open DevTools, watch the Network tab, and you will see exactly one outbound request whose path contains five characters and nothing else.

A worked example: what "leaked" actually looks like

Let's run a real one. Type the password Summer2024! — a pattern millions of people consider safe because it has an uppercase letter, digits, and a symbol.

The tool hashes it, sends the prefix, gets the candidate list back, finds a match locally, and shows you something like: Found — count 12,000+. That count is not "12,000 people who got hacked." It is the number of times that exact string has appeared across all the breach dumps HIBP has ingested — LinkedIn 2012, Adobe 2013, Collection #1, and over 600 others. A count above zero means the string is already on the lists attackers buy and load into credential-stuffing tools. For contrast, paste 123456 and the count comes back north of one million; it is the first guess any automated attack makes.

Now the key insight: Summer2024! is not "weak" in the password-meter sense. It is twelve characters with mixed case, a number, and a symbol. It fails not because it is short or simple but because thousands of other people independently thought of the same clever pattern, and one of them was in a breach. Once a string is in the corpus, its theoretical strength stops mattering. Attackers don't brute-force it; they look it up.

Reuse is the real risk, not weakness

This is the part people get backwards. We obsess over making passwords "complex" and ignore the thing that actually causes takeovers: using the same password in more than one place.

Here is why the count even matters. When a site you use gets breached, attackers don't just try the stolen credentials on that site — they replay your email-and-password pair against banks, email providers, and everything else, betting you reused it. That replay is called credential stuffing, and it is the dominant account-takeover method by volume. A leaked password is dangerous in direct proportion to how many places you used it. A unique password that leaks costs you exactly one account. A reused password that leaks costs you all of them.

So a "count of 0" is not a gold star. It only means the string is not in a public dump yet. Xq7 returns a count of 0 too, and it is broken in seconds. And changing monkey1 to monkey2 after it leaks fools nobody — attacker rule sets test those trailing-digit and trailing-symbol mangles first, so your "new" password is cracked before you finish typing it. Length and uniqueness beat cleverness every time.

I checked my own old password and stopped arguing

I'll be honest about why I trust this. Years ago I had one "good" password I rotated across maybe eight accounts, with a site-specific tweak on the end that I was quietly proud of. The first time I pasted the base string into a leak checker, the count came back in the tens of thousands. My private, clever, hand-crafted password was a line in a dictionary that thousands of strangers had also independently invented. Seeing an actual number — not a lecture, not a red meter, a hard integer — did what no security blog ever managed: I opened a password manager that afternoon and never typed a memorized password into a new signup again. If you have a relative who insists their password is "complicated enough," skip the argument and show them the number.

You got a hit — here is the exact playbook

If a password comes back leaked, do these in order, today:

Change it everywhere you used it. Assume reuse is already being exploited. Start with your email account and anything that resets via email, because that is the master key to everything else.
Do not just append a digit or symbol. password! is not an upgrade over password. Generate a fresh, fully random 20-character string instead. The Password Strength Checker catches the obvious junk locally with zero network calls, so it is a good first pass before you commit to anything; pair it with a manager that generates the random strings for you.
Turn on two-factor authentication on the affected accounts — a TOTP app rather than SMS where you have the choice, since SMS codes can be intercepted via SIM swaps.
Look up which breach exposed it at haveibeenpwned.com/account. Knowing the specific incident tells you what else leaked alongside the password — email, security questions, partial card numbers — so you can rotate those too.

The deeper fix, the one that makes the whole leak question mostly academic, is a password manager. Bitwarden, 1Password, and KeePassXC all work; Bitwarden is free and audited. Generate a unique 20-plus-character random password for every site, store them all in the vault, and memorize exactly one strong master phrase. After that, a breach at any single site exposes one unique string and touches nothing else you own. A leak checker is the diagnostic; a password manager is the cure. Run the check when you're curious, then go set up the thing that means you never have to worry about the answer again.

Made by Toolora · Updated 2026-06-13