Password Breach Checker — Has Your Password Been Leaked?
Check any password against 850M+ breached passwords from 800+ data breaches. SHA-1 hashed locally — your password never leaves your browser. Verifiable in DevTools.
🔑
🔒 Your password is hashed locally (SHA-1). Only the first 5 characters of the hash are sent to the API. Your actual password is never transmitted.
How k-Anonymity Keeps You Safe
🔑
Enter Password
Type the password you want to check
#️⃣
SHA-1 Hash
Password is hashed locally in your browser
✂️
Send Prefix Only
Only the first 5 chars of the hash are sent
🔍
Match Locally
Full hash is compared against results in your browser
What this tool does
The Password Breach Checker tells you whether a specific password has appeared in any of 800+ publicly disclosed data breaches. Type the password, get a definitive yes-or-no answer in under half a second, and if it has been seen, find out roughly how many unique sightings there are across the breach corpus. The check is anonymous, requires no account, and works for any password you can type. It is the simplest way to verify whether the credentials you reuse — the ones for email, social media, banking, that "throwaway" account from 2014 — are already in attacker dictionaries.
What is different about this tool: your password literally never leaves your browser. It is hashed locally with SHA-1, and only the first 5 characters of that hash are sent to the breach database. The actual comparison happens in your browser against the response. This is k-anonymity — the same technique used by 1Password, Firefox, and government password security guidance — and you can verify it works as described by opening DevTools and watching the network tab. We also fall back to a second breach database (XposedOrNot) when HIBP is rate-limiting, so the checker answers reliably even during HIBP outages. No account required. No logs kept. No emails captured.
How it works under the hood
The lookup uses k-anonymity against the Have I Been Pwned (HIBP) Pwned Passwords API — the canonical breach password database maintained by Troy Hunt, with 850M+ unique passwords from 800+ public data breaches. When you type a password and hit Check, three things happen, in this order.
1. Local hashing. Your browser computes the SHA-1 hash of your password using the Web Crypto API. The full password is now a 40-character hex hash. This hash never leaves your machine.
2. Prefix-only request. Only the first 5 characters of the hash are sent over HTTPS to api.pwnedpasswords.com/range/[5-char-prefix]. The HIBP server responds with every breached-password hash that starts with those 5 characters — typically 400–600 results, returned as plain text.
3. Local match. Your browser compares the remaining 35 characters of your hash against the response, in JavaScript, locally. If a match is found, the count from the HIBP response is displayed. If not, the result is "clean".
The HIBP server learns only that someone checked a password whose hash starts with those 5 characters — which corresponds to ~500 possible passwords. It cannot determine which specific password was checked. This is the same protocol Apple iCloud Keychain and Google Password Checkup use.
Rate limits and why they exist. The tool is rate-limited to 30 checks per IP per hour. This is generous for personal auditing and tight enough to discourage credential validation at scale — actual credential-stuffing operations do not use this tool anyway, they download the entire HIBP password file (28 GB, free) and run lookups locally.
No logging. The server records nothing about your check beyond the IP-bound rate-limit counter, which expires after one hour. There is no application log of which prefixes were queried, no analytics on which passwords were checked, and nothing in any database. The check leaves no forensic trace on our infrastructure — verifiable because there is nothing to subpoena.
Five real-world use cases
Audit a password you've reused for years
You set up an account in 2014 and reused the same password for the next decade across forums, free trials, and one email account you forgot you had. Even if every individual account is low-value, a password reused that long is statistically certain to be in multiple breaches by now. Check it once. If it returns hits in the thousands, retire it permanently — every account using it is being actively tested by credential-stuffing automation, and the cost of changing it is one afternoon of password-manager work versus an indefinite tail of account takeovers.
letmein123
Vet a new password before committing to it
You're setting a password for a high-value account — primary email, banking, password manager master. Before committing, paste the candidate here. Strong-looking passwords like 'Spring2026!' or 'BlueSky42' look reasonable but appear in many breaches because thousands of people independently picked them. The pattern of capital + word + year + symbol is so predictable it's been generated by attackers and seeded into wordlists for years. If your candidate returns even a handful of hits, generate a fresh one — preferably from a password manager's CSPRNG, not your own brain.
MyN3wP@ssw0rd!
Pre-flight check before importing into a password manager
You're switching password managers and exporting your old vault. Before importing, audit each password individually — most managers have built-in breach monitoring, but doing it manually for the first ~50 entries surfaces the worst offenders fast. Anything in the breach corpus gets regenerated to a fresh 20-character random string immediately, before it becomes part of your new vault. Also worth doing on a freshly imported vault from a CSV export, where some line-noise passwords from old browser autofills will turn out to be standard wordlist entries you'd forgotten about.
Bug bounty: validate found credentials in scope
You discovered credentials during an authorised engagement — a public GitHub commit, an exposed .env file, a leaked Pastebin paste, a misconfigured CI artifact. Before reporting, check the password here. If it returns thousands of sightings, the credential is in every wordlist already — your finding is real but the impact narrative is weaker. If it returns zero, you've found something fresh and the report carries materially more weight (and usually a higher payout). Document the HIBP count in your report — triagers appreciate the context, and it pre-empts the 'is this novel?' question. Earns 50 XP per check on the SecurityElites platform.
Post-breach triage when a service you use is compromised
A service you use just announced a breach. They claim 'passwords were hashed' but you want to verify the practical impact. Check the password you used on that service — if it's in the breach corpus within 48 hours of the announcement (usually true regardless of what 'hashed' meant in the breach disclosure), the hashing didn't help. Change it everywhere it was reused, today, starting with email and any account that holds payment data. Bookmark this tool now so you have it ready when an incident notification arrives — most breach announcements arrive at inconvenient times and you don't want to be searching for a checker mid-triage.
Common mistakes & edge cases
Why am I getting 'not found' when I know my email was in a breach?
The two checks are independent. The Password Breach Checker tells you whether the specific password string appears in any breach. The Email Breach Checker tells you which breaches your email address has appeared in. Your email might be in many breaches but the password from those breaches might be different from what you're checking now. Run both.
Why is my unique 30-character password showing as compromised?
Either it's not as unique as you think (someone independently picked the same string — try character-for-character) or the source is copy-paste from somewhere public (a tutorial, a screenshot, a forum example). Truly random 30-character passwords have effectively zero collision probability. If a long password matches, regenerate it from a CSPRNG and never reuse the source location.
Should I trust this tool with my real password?
Don't take our word for it — verify. Open your browser's DevTools, switch to the Network tab, and run a check. You'll see exactly one outbound request, to api.pwnedpasswords.com/range/XXXXX where XXXXX is 5 hex characters. Your password is not in the URL, not in any request body, not anywhere on the wire. The privacy guarantee is verifiable in 30 seconds — that's the point of k-anonymity.
Why does the count change if I check the same password twice?
The HIBP database updates continuously. If a new breach was published between your two checks, the count goes up. The count never decreases — if you're seeing decreases, you almost certainly typed two different passwords with similar hashes. Recheck character-by-character, paying attention to capital I vs lowercase l vs the digit 1.
Can attackers use this tool to validate stolen passwords?
In theory yes, which is why we rate-limit to 30 checks per IP per hour. At scale, attackers don't use this tool anyway — they download the entire HIBP password list (28 GB, free, no key required) and run their lookups locally. Our rate limit defends against opportunistic abuse, not determined adversaries — that would be impossible without breaking the service for legitimate users.
Does 'not found' mean the password is safe to use?
No. 'Not found' means the password hasn't appeared in a publicly disclosed breach. Private breaches that haven't reached HIBP — and there are many — won't be detected. A weak password that nobody has bothered to leak yet is still a weak password. Always pair the breach check with the Password Strength Checker, and assume any password under 12 characters is bruteforceable on consumer GPU hardware regardless of its breach status.
Your Privacy Is Protected
This tool uses the Have I Been Pwned (HIBP) Pwned Passwords API with k-anonymity. Your password is never sent over the network in any form — only a partial hash prefix is transmitted.
🔒 Password hashed client-side (SHA-1)
✂️ Only first 5 hash chars sent to API
🚫 Full password never leaves your browser
🗑️ Nothing stored — zero logs
🌐 Open-source API by Troy Hunt
✅ Used by 1Password, Firefox, and governments
How to Create Strong Passwords
✓Use at least 12 characters — longer is always stronger
✓Mix uppercase, lowercase, numbers, and special characters
✓Never reuse the same password on multiple websites
✓Use a passphrase — 4+ random words (e.g. "correct-horse-battery-staple")
✓Use a password manager like Bitwarden, 1Password, or KeePass
✓Enable Two-Factor Authentication (2FA) on every account
✓Change passwords immediately if any service you use is breached
Frequently Asked Questions
Paste the password into the checker above to find out. We'll tell you within half a second whether it appears in any of the 800+ public breaches HIBP tracks, and roughly how many unique sightings exist. The password is hashed in your browser before any network request — only the first 5 characters of the SHA-1 hash leave your machine, so we never see what you checked.
Yes, and it's verifiable. We use k-anonymity hashing — the same technique 1Password, Firefox, Apple iCloud Keychain, and government password guidance all rely on. Open your browser's DevTools, switch to the Network tab, and run a check. The only outbound request is to api.pwnedpasswords.com/range/[5 hex chars]. Your full password and full hash never leave your browser.
K-anonymity is a privacy technique where instead of sending the password (or its full hash) to a server, only a short prefix of the hash is sent. The server returns every breached hash starting with that prefix — typically around 500 results — and your browser does the actual comparison locally. The server never learns which specific password was checked, only which bucket of ~500 candidates it belongs to.
HIBP is a free service maintained by Troy Hunt that tracks publicly disclosed data breaches. The Pwned Passwords subset — which this tool uses — contains 850M+ unique compromised passwords from over 800 breaches, queryable via a public k-anonymity API with no authentication required. It's the canonical reference for password breach data, used by 1Password, Firefox, governments, and password managers worldwide.
Change it on every account where you've reused it, starting with email and banking. Move to a password manager that auto-generates 20+ character unique passwords. Enable a FIDO2 hardware key on critical accounts. Don't reuse the leaked password ever again, even on accounts you don't care about — credential-stuffing automation tests exposed passwords against every service, regardless of how unimportant the original account was.
No. Once a password appears in a public breach, it is in attacker wordlists used in credential-stuffing attacks against every major service. Even if the original breach was a low-value site you don't use anymore, the password itself is permanently burned. Change it everywhere you've ever used it.
Continuously. HIBP typically ingests new breaches within 24–72 hours of public disclosure. Smaller breaches are added quickly; very large ones (50M+ records) may take weeks to fully process. This tool always queries the live HIBP API — you're checking against the most current data available, not a stale snapshot.
Probably someone else made it up first. Common phrases — quotes, song lyrics, memes, 'correct horse battery staple' itself — get adopted by thousands of independent users and end up in breaches the moment any one of those users is breached. If your passphrase contains any common reference, it's likely been picked by others too. Use a Diceware-style random word generator instead of inventing the words yourself.
A password check tells you whether the specific password string appears in any breach — useful for vetting passwords before or after use. An email check tells you which breaches your email address has appeared in — useful for understanding overall account exposure. They answer different questions; run both. Use the Email Breach Checker for the email side.
Yes, for your own passwords. Querying breach databases for credentials you control is unambiguously legal everywhere we're aware of. Querying credentials belonging to other people without authorisation may be illegal in some jurisdictions — the rate limit (30 checks per IP per hour) is calibrated for individual auditing, not third-party investigation.