🕵️ Have-I-Been-Exposed Hash Checker

Your Password Checker Is Probably Lying to You About What "Safe" Means

There's a particular kind of false comfort that comes from typing a password into a website and getting a green checkmark. Twelve characters, uppercase, a number, a symbol — you've followed every rule and the strength meter glows satisfyingly. What that meter cannot tell you, and what most people genuinely don't know, is whether that exact password — or a variation of it — already exists in a criminal database with billions of entries. A strong-looking password that has already been stolen is no stronger than "123456".

That's the gap that breach databases like Have I Been Pwned (HIBP) were designed to fill. But using them introduces a problem that sounds almost philosophical: to find out if your password has been exposed, you'd normally have to send your password somewhere — which is exactly what you shouldn't do. This is not a hypothetical concern. Sending plaintext passwords over any network, even to a service you trust, creates exposure that simply doesn't need to exist.

SHA-1 Is "Broken" — And That's Precisely Why It's Used Here

Here's the irony that trips most people up. SHA-1 was deprecated for use in digital certificates and signatures around 2017 because researchers demonstrated collision attacks — meaning two different inputs could produce the same hash. Security professionals moved to SHA-256 and beyond for anything requiring collision resistance.

Yet HIBP's breach database indexes passwords by their SHA-1 hashes. Why use a "broken" algorithm? Because collision resistance is irrelevant for password breach lookups. What matters here is a different property: preimage resistance. Even with all known SHA-1 weaknesses, nobody can take a SHA-1 hash and reverse it back to the original password in any practical timeframe. The hash acts as a one-way fingerprint, not a lockbox with a known key. Forging a certificate is a completely different attack from reconstructing a password — and SHA-1 still resists the latter very effectively at current computing scales.

So when you hash "hunter2" with SHA-1 and get F3BBBD66A63D4BF1747940578EC3D0103530E21D, that string is what lives in breach databases. No breach database ever stored your actual password — they stored (or rather, attackers exfiltrated) these hashes, and then cracked the weak ones offline using dictionary attacks and rainbow tables.

What K-Anonymity Actually Does (And Why Five Characters Is the Right Number)

The clever part of the HIBP API design is a privacy technique borrowed from data science called k-anonymity. The principle: you should be able to query a dataset without revealing which specific record you're asking about.

Here's how it works in practice. You hash your password locally — entirely on your own machine — and take only the first five hexadecimal characters of that hash. You send just those five characters to the HIBP API. The server responds with every hash suffix in its database that starts with those same five characters, typically between 400 and 900 results. You then compare the full hash you computed locally against this list, entirely offline, to see if your specific hash appears. The server never learns your full hash, and certainly never learns your password.

Why five characters specifically? Each hex character represents four bits, so five characters give you 20 bits of addressing — that's 1,048,576 possible prefix buckets. With around 800 million breached password hashes in the database, each bucket returns roughly 750 results on average. That's a comfortable anonymity set: your query is indistinguishable from hundreds of other queries that share your prefix. Fewer characters would return too many results and make the API slow; more characters would narrow the anonymity set too much, potentially making your specific hash identifiable from traffic analysis alone.

The Local Computation Is Non-Negotiable

This tool uses your browser's native SubtleCrypto API — specifically crypto.subtle.digest('SHA-1', data) — which is the same cryptographic engine that your browser uses for TLS certificate verification. No JavaScript library is loaded. No external code runs. The hashing happens in a sandboxed environment that never touches a network socket.

You can verify this yourself. Open your browser's network inspector before clicking the compute button. You'll see zero outbound requests. The SHA-1 digest is computed in memory, the first five hex characters are extracted, and that's what you see on screen. The rest of the process — actually querying the HIBP API with that prefix — is something you'd do separately, in your own browser, if you choose to.

This separation is intentional and important. A tool that computes the hash and automatically queries the API would be convenient, but it would also be making a network call with a derivative of your password. Whether or not that specific risk is meaningful, removing the automatic call makes the tool's behavior completely transparent and auditable.

Common Misconceptions Worth Clearing Up

People often ask whether seeing their hash prefix in the API response means their password is definitely compromised. The answer requires a small distinction. If your full SHA-1 hash appears in the breach database, it means that exact password string was found in at least one breached dataset. It does not mean your specific account was breached — only that the password itself has been used by someone, somewhere, who was breached, and attackers now have it in their dictionaries. Either way, retire it.

Another common confusion: hashing a password is not the same as encrypting it. Encryption is reversible with a key. SHA-1 is a one-way function — there's no "SHA-1 decryption." When you see tools online claiming to "decrypt SHA-1 hashes," what they're actually doing is looking up pre-computed hash tables (rainbow tables) and hoping your password was common enough to appear. A genuinely random 16-character password will not be crackable this way regardless of which hash function was used.

One more: this tool works on the raw password string, not on your stored authentication credentials. Websites that do security correctly store a salted hash — they run your password through bcrypt, scrypt, or Argon2 with a random salt unique to your account. That stored hash will not match anything in the HIBP SHA-1 database. What you're checking with this tool is whether your chosen password string itself appears in known breach lists — a meaningful check before you decide to use that string as a password anywhere.

When This Actually Matters in Practice

The realistic threat model for most people isn't a targeted attack against their specific account. It's credential stuffing — automated tools that take username/password pairs from old breaches and try them against banking sites, email providers, and online stores. If you reused a password from a 2012 gaming forum breach, that password is in attacker wordlists right now, being tried against your email address at thousands of sites per hour.

Checking the SHA-1 prefix before committing to a new password takes about three seconds. Finding out your reused password has appeared in 47,000 breach records before you use it on your bank account is significantly better than finding out after. The k-anonymity design means you can make this check without trusting any external server with anything sensitive — which makes it one of the more elegantly designed privacy-preserving security checks available to ordinary users.

The five characters you see highlighted in this tool's output are your entry point into that process. What you do with them is your call.