A website can tell you whether your password has appeared in a leak without receiving the password itself. On Have I Been Pwned's password checker, your browser does the private part of the work and sends only a small piece of a code.
Try the example password P@ssw0rd. A check on September 7, 2026 returned more than 6 million appearances in leaked data. The animation illustrates that result using a recreated page, rather than a recording of the current website. Use an example when following the demonstration, rather than typing a real password into an unfamiliar page.
Five characters go out
Your browser turns the password into a 40-character code called a SHA-1 hash. It sends the first five characters to the service, which replies with the leaked hash endings that match that start. Your browser searches the reply for the rest of its code and reads the count beside it.
The full password and its full hash stay in your browser during this check. The service sees a group of possible matches, rather than a request for one exact password. It learns less than it would from the full code, though that doesn't mean it learns nothing.
First, the example password becomes a hash on the local machine. The five characters in amber are the part used for the request.
The request for 21BD1 returned 1,925 hash endings in this demonstration. That count can change as the service adds leaked passwords.
The final search happens locally. The matching row contains the remaining 35 characters and the number of times the password appeared.
In 2018, Junade Ali, then at Cloudflare, proposed using an existing privacy idea called k-anonymity for leaked passwords. He worked with Troy Hunt on Pwned Passwords version 2, which launched that February. Five characters split the collection into just over a million possible groups. Sending fewer would mean larger replies, while sending more would narrow the set of passwords that could match.
Troy Hunt's launch explanation, Cloudflare's explanation of the privacy tradeoff
Small details affect privacy
The amount of data in a reply can reveal clues about which group was requested. Apps can ask the service to add fake rows, making the replies harder to identify by size. Those rows have a count of zero and get ignored when the app checks for a match.
Developers also need to wait until someone has finished typing. Checking after every keystroke sends a series of related requests that could help an observer work out the password. One completed entry should produce one check.
This is a method for checking leaked passwords, not a way to store new passwords securely. Someone with a likely password can calculate its hash and compare it with a stored hash. Turning a weak password into a hash doesn't make that password hard to guess.
Pwned Passwords range, padding and incremental-search guidance
Watch the request yourself
Open the password checker and your browser's developer tools, then select the Network tab. Submit the example password and look for the request whose address ends in range/21bd1. The service accepts either letter case. The service receives that five-character start along with ordinary connection details such as your IP address.
The recreated browser animation below uses uppercase characters. Its layout, timing and transfer-size labels are illustrative. The current website uses lowercase characters for the same request.
Bitwarden uses Pwned Passwords for its Exposed Passwords report. That doesn't mean every password check on every website happens in your browser. A site you sign in to may receive your password through its normal login process and perform a leak check on its server.
A match means the password is in a list that attackers can try on other accounts. Replace it wherever you use it and give each account its own password. No match only means it wasn't found in this collection, not that the password is strong or has never been stolen.
Bitwarden's exposed-password report, Bitwarden's Pwned Passwords implementation
