Your password never leaves this page. We use the k-anonymity model -- your browser hashes your password with SHA-1 and sends only the first 5 characters of the hash to the API. The server returns matching hash suffixes and your browser checks locally. The API never sees your password or full hash.
Try one of these known-bad examples to see how the tool works
What this tool does
Free password breach checker -- check if your password was leaked using HIBP k-anonymity
How this leaked password checker works technically and why it is completely safe to use
This free password breach checker uses the Have I Been Pwned Pwned Passwords API with the k-anonymity privacy model to check whether your password has appeared in any known data breach dataset. When you enter a password and click Check, your browser first computes the SHA-1 cryptographic hash of your password entirely locally using the Web Crypto API -- this produces a 40-character hexadecimal string. Your browser then sends only the first 5 characters of that hash to the HIBP API over HTTPS. The API returns all hash suffixes that begin with those 5 characters -- typically 400 to 900 results. Your browser then scans this list locally to see whether your full hash suffix appears, and if it does, reads the breach count alongside it. Your actual password and the full hash are never transmitted at any point in this process.
The k-anonymity model was co-designed by Troy Hunt and Cloudflare engineers specifically to make breach checking safe enough to use with real passwords. The mathematical basis is straightforward: a 5-character prefix of a 40-character hexadecimal hash is shared by approximately 1 in every 1,048,576 possible hashes, meaning every query returns matches for hundreds of entirely different passwords. The server cannot determine which specific password you checked from the prefix alone -- the query is indistinguishable from queries for hundreds of other passwords. This design is also used by Google's Password Checkup feature, Mozilla's Firefox Monitor, and 1Password's Watchtower, all of which query the same HIBP endpoint. The HIBP Pwned Passwords dataset itself contains over 800 million real-world password hashes collected from publicly disclosed breaches at companies including LinkedIn, Adobe, Dropbox, Yahoo, MySpace, RockYou, and hundreds of others.
Understanding why a breached password is dangerous requires understanding credential stuffing attacks. When attackers obtain a username and password from one breached database, they run automated tools that systematically test that combination against thousands of other websites -- banking portals, email providers, e-commerce platforms, and social networks. These tools can attempt thousands of login attempts per second and are continuously running against every major platform. If your password appears even once in a breach database, it is already in the wordlists these tools use. Password reuse is the reason credential stuffing is so effective -- the average internet user reuses the same password across 14 different accounts, meaning a single breach at one low-security website can give attackers access to the user's most sensitive accounts. This tool helps you identify which passwords need to be changed before that happens.
How the k-anonymity check works
1
Hash locally
Your browser hashes the password with SHA-1, producing a 40-character hex string. Example: 'password' -> 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
2
Send only prefix
Only the first 5 characters ('5BAA6') are sent to the HIBP API over HTTPS. The remaining 35 characters stay in your browser.
3
Get candidates
The API returns all hash suffixes starting with your 5-char prefix -- typically 400-900 results covering thousands of different passwords.
4
Match locally
Your browser checks if your suffix appears in the returned list. The count next to it shows how many times that password appeared in breaches.
Features and security guarantees
800M+ Passwords
Searches over 800 million real-world leaked password hashes from hundreds of publicly known data breaches.
k-Anonymity Model
Mathematically guarantees the API cannot determine which specific password you checked from the 5-char prefix alone.
Local SHA-1 Hashing
Your browser computes the SHA-1 hash using the Web Crypto API -- the password never touches any network request.
Breach Count
Shows exactly how many times the password appeared in breach datasets -- a higher count means higher active attack risk.
Four Risk Tiers
Not found / Seen in breaches / Commonly breached / Extremely compromised -- each with specific remediation advice.
Actionable Steps
Every breached password result includes four numbered remediation steps to follow immediately.
Show/Hide Toggle
Toggle password visibility for safe use in public environments without sacrificing usability.
Example Passwords
Try three known-bad passwords with one click to understand what different risk levels look like.
No Signup
Free to use immediately with no account, no API key, no email address, and no rate limits.
Results in Seconds
Live API checks via the Cloudflare-hosted HIBP endpoint typically complete in under 2 seconds.
Examples
Password breach examples -- from zero exposure to 24 million records
Five real passwords and their breach database results, from the most-leaked password on the internet to a safely generated one
Failpassword123 -- found 2.3 million times, extremely compromised
Password: password123
SHA-1 prefix: 5BAA6 (sent to API)
Breach count: 2,390,819 times
Risk level: Extremely compromised
One of the most commonly used passwords on the internet, appearing in over 2.3 million breach records. Every password cracking tool and credential stuffing list contains this password. Any account using it is effectively unprotected regardless of other security measures. Change it immediately and never use simple word-plus-number combinations.
Fail123456 -- found 24 million times, the most-breached password ever
Password: 123456
SHA-1 prefix: 7C4A8 (sent to API)
Breach count: 24,230,577 times
Risk level: Extremely compromised
The most frequently appearing password in the entire HIBP database with over 24 million breach records. It is the default or first-choice password for millions of users globally and is the very first password tried in every automated attack. No account using this password should be considered secure for even a moment.
WarningTr0ub4dor&3 -- the famous xkcd password, still in breach databases
Password: Tr0ub4dor&3
SHA-1 prefix: 4A8DA (sent to API)
Breach count: 2 times
Risk level: Seen in a small number of breaches
This password was made famous by the xkcd 'correct horse battery staple' comic as an example of a hard-to-remember but seemingly strong password. It now appears in breach databases because of its notoriety. Even low breach counts are a warning -- if a password is publicly known as an example, attackers include it in their wordlists.
Warningcorrect horse battery staple -- the xkcd passphrase, also indexed
Password: correct horse battery staple
SHA-1 prefix: D0B2E (sent to API)
Breach count: 1 time
Risk level: Seen in a small number of breaches
The xkcd passphrase itself -- famous as an example of a strong, memorable passphrase -- now appears in breach databases because millions of people used it literally after the comic was published in 2011. This illustrates the core rule: any password from a public example, song lyric, movie quote, or widely shared source is already in attacker dictionaries.
PassxK#9mP$2vL@nQ7 -- randomly generated, zero breach records
Password: xK#9mP$2vL@nQ7
SHA-1 prefix: 3F8A2 (sent to API)
Breach count: 0 times
Risk level: Not found in any breach
A randomly generated 14-character password with mixed case, numbers, and symbols. Zero breach records means it has not appeared in any dataset known to HIBP. This is what a safe password looks like -- long, random, unique, and generated by a password manager rather than chosen by a human. Use a different randomly generated password for every single account.
FAQ
Frequently asked questions about password breach checking and HIBP
Common questions from users about leaked password databases, k-anonymity, credential stuffing, and password security best practices
Is it safe to check my password with this tool?
Yes -- this tool uses the k-anonymity model from the Have I Been Pwned Pwned Passwords API, which was co-designed by security researcher Troy Hunt and Cloudflare specifically to make breach checking safe. Your browser computes a SHA-1 hash of your password locally and sends only the first 5 characters of that 40-character hash to the API over HTTPS. The server returns all hash suffixes that start with those 5 characters -- typically 400 to 900 results. Your browser then checks locally whether your full hash suffix is in the returned list. Your actual password and the full hash are never transmitted to any server under any circumstances.
What is k-anonymity and how does it protect my password?
K-anonymity is a privacy preservation technique that ensures your specific query cannot be distinguished from many other queries. When you send only a 5-character prefix of a 40-character SHA-1 hash, the server receives a query that matches hundreds of possible different passwords -- it is mathematically impossible for the server to determine which specific password you are checking. The server returns all matching hash suffixes and your browser performs the final comparison locally. This design means the HIBP API operator, network observers, and any intermediary could never learn which password you checked, even if they logged every request.
What is Have I Been Pwned and how does the Pwned Passwords database work?
Have I Been Pwned (HIBP) is a free data breach aggregation service created by security researcher Troy Hunt in 2013. It collects password hashes from hundreds of publicly known data breaches and makes them searchable without exposing the actual passwords. The Pwned Passwords dataset contains over 800 million real-world password hashes derived from breaches at companies including LinkedIn, Adobe, Yahoo, RockYou, and many others. The dataset is freely downloadable for offline use or accessible via the k-anonymity API. Finding your password in this database means it was directly leaked in at least one known breach and is now in the wordlists used by attackers in credential stuffing and dictionary attacks.
My password was not found -- does that mean it is safe to use?
Not found in the HIBP database means this exact password string has not appeared in any breach dataset that HIBP has indexed -- it does not mean the password is strong, secure, or resistant to other attacks. A password can be short, dictionary-based, predictable, or easily brute-forced without ever having been directly leaked in a breach. Passwords like 'Abc123!' or 'Summer2024' are not in breach databases but would be cracked instantly by any modern password attack tool. Always use a long, randomly generated unique password of at least 16 characters for every account, regardless of the breach check result.
What should I do immediately if my password is found in a breach?
Change the breached password immediately on every account where you use it -- not just the one you were thinking of, since password reuse is extremely common. Generate a unique, randomly generated password for each account using a password manager like Bitwarden (free and open source), 1Password, or Dashlane. Enable two-factor authentication (2FA) on every account that supports it, prioritising email, banking, and social media. If your email account password was breached, treat every account that uses that email address for password reset as potentially compromised and change those passwords too. Check your email address at haveibeenpwned.com to see which breaches it appeared in.
How does SHA-1 hashing protect my password in this process?
SHA-1 is a one-way cryptographic hash function -- given a password like 'hunter2', it produces a fixed-length 40-character hexadecimal string, but it is computationally infeasible to reverse the hash back to the original password. When this tool computes the SHA-1 hash of your password locally in your browser, the hash itself reveals nothing useful about the password to an observer who sees only the first 5 characters. SHA-1 is no longer considered secure for new cryptographic applications because of collision vulnerabilities, but for this specific use case -- indexing known compromised passwords in a breach database -- it provides completely adequate privacy protection because the k-anonymity model means the full hash is never transmitted.
What is credential stuffing and why does a breached password make it dangerous?
Credential stuffing is an automated cyberattack where attackers take username and password combinations leaked in one breach and systematically test them against hundreds of other websites and services. Because most people reuse the same password across multiple accounts, a single breach at one company can give attackers access to the victim's accounts at banks, email providers, social networks, and e-commerce sites. Tools that perform credential stuffing can attempt thousands of logins per second across multiple platforms simultaneously. If your password appears in a breach database with even a small count, it is already in the wordlists used by these automated tools and any account using that password is actively at risk.
How often should I check my passwords for breaches?
Run a breach check whenever you create a new password to confirm it has not already been compromised, when you hear about a major data breach at a company where you have an account, and periodically (every 6 to 12 months) for your most sensitive accounts. Password managers like Bitwarden and 1Password now offer automated breach monitoring that continuously checks your stored passwords against updated breach databases and alerts you when any of them appear in new breach disclosures. For business accounts and developer environments, consider integrating the HIBP API directly into account creation flows to prevent users from setting already-compromised passwords.
Can I use this to check passwords for my users or application?
Yes -- the Have I Been Pwned Pwned Passwords API is publicly available and free for reasonable use. For application integration, you can implement the same k-anonymity model: hash the user's password with SHA-1 at input time, send the 5-character prefix to the API, and check if the returned suffixes include a match before allowing the password to be set. This is now recommended by NIST (National Institute of Standards and Technology) in their digital identity guidelines (SP 800-63B), which explicitly state that new passwords should be checked against known compromised password lists. Many authentication libraries and identity platforms have built-in HIBP integration.
What is the difference between a password breach check and a password strength check?
A password breach check searches a database of real-world leaked passwords to determine if your exact password has been exposed in a known data breach -- it is backward-looking and factual. A password strength check analyses the structural properties of a password (length, character variety, entropy, common patterns) to estimate how difficult it would be to crack by brute force or dictionary attack -- it is predictive and probabilistic. Both checks serve different purposes and neither is a substitute for the other. A password can be structurally strong (long, random-looking) but still appear in breach databases if it was previously used and leaked. The ideal approach is to use a randomly generated password that passes both checks.
Related Security Tools
Need a disposable email address?Stop giving your real address to sites you don't trust -- get a free instant throwaway with no signup and no trace.
Get Free Temp Mail ->