b2KIT

Data Breach Password Checker

Check if a password has appeared in known data breaches using k-anonymity with the HIBP API hash prefix.

Tested tool guide Tested browser tools Checked August 16, 2026

What Data Breach Password Checker does and how it behaves

A password entered here is checked against Have I Been Pwned's Pwned Passwords corpus without sending the password itself. The browser computes its SHA-1 digest, submits only the first five hexadecimal characters, and compares the remaining characters with the returned candidates. The common surprise is that a positive result does not identify the breach, account, website, or date involved. It means HIBP has recorded that password digest in breach-derived data, so the password should be replaced wherever it is still used.

How the result is produced

1

Five-character prefix lookup

The browser computes the password's 40-character SHA-1 digest. The lookup request contains only its first five hexadecimal characters, not the plaintext password or complete digest. HIBP returns candidate suffixes belonging to hashes with that prefix, together with their prevalence counts. This k-anonymity design avoids directly disclosing which complete hash is being checked.

2

Exact suffix comparison

The browser compares the remaining 35 digest characters with the suffixes in the response. An exact match marks the password as found and links it to the count returned for that hash. No match means the current HIBP corpus did not return that digest. It does not measure length, randomness, reuse, resistance to guessing, or overall password strength.

Good uses

  • Checking an existing password before replacing it, especially when it has been reused or has remained unchanged for a long time.
  • Screening a proposed password to see whether its digest is already represented in HIBP's collection of exposed passwords.
  • Showing why a familiar or commonly reused password should be retired, even when no compromise of a specific personal account is known.

Limits and checks

  • A not-found result is not evidence that the password is strong, unique, or secret. The corpus cannot contain every password exposed in every incident.
  • A found result cannot identify which breach supplied the password, which account used it, or whether any of your own accounts were involved.
  • The reported count is prevalence within HIBP's collected data. It is not a count of your accounts, unique people, affected websites, or currently usable credentials, and it may change as the corpus is updated.

Common questions

Does HIBP receive the password I enter?

No. This check sends the first five characters of the password's SHA-1 digest, while the plaintext password and remaining digest characters stay in the browser. HIBP returns many candidate suffixes sharing that prefix, and the browser performs the exact comparison. K-anonymity limits what the lookup reveals, but it does not turn an exposed password into a safe one.

Can I safely use a password if the result says it was not found?

No. Not found means only that this exact digest was absent from the returned HIBP data at the time of the check. A password can still be predictable, reused, recently exposed, or missing from the corpus. Use a unique, randomly generated password for each account and store it in a password manager when possible.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools