Live · privacy-safe (k-anonymity)

Password Breach Checker

Check whether a password has appeared in known data breaches. We hash it in your browser and send only the first 5 characters of the hash — your actual password never leaves this page.

Show Check

Powered by the Have I Been Pwned range API. Never reuse a password that appears here.

Why password breach checking matters for your app

A password breach checker tells you whether a given password has appeared in a publicly known data breach. When users reuse passwords — and most do — an attacker who obtains your password list from one breach can try every entry against every other site the user has an account on. This is called credential stuffing, and it accounts for billions of automated login attempts every month.

How Have I Been Pwned works

This tool uses the Have I Been Pwned (HIBP) k-anonymity API. Your password is hashed with SHA-1, but only the first 5 characters of the hash are sent to the API. The API returns all hashes matching those 5 characters, and the comparison happens locally. Your full password never leaves your device — this is a privacy-preserving design that lets you safely check passwords without exposing them to any third party.

What to do when a password appears in a breach

If a password your users might choose is in a breach database, block it at registration time. Do not just warn users — prevent the password from being set. NIST SP 800-63B explicitly recommends checking new passwords against known breach lists and rejecting matches. A password like "Summer2024!" appears in breach databases despite meeting most complexity requirements.

Credential stuffing attacks on vibe-coded apps

AI-built apps rarely implement rate limiting on login endpoints or integrate breach-checking at registration. This makes them high-value targets for automated credential stuffing tools. An attacker can test thousands of username and password combinations per minute against an unprotected endpoint. Adding breach checking at signup and rate limiting at login are the two controls that make this attack class impractical.

Building it into your app

At registration, hash the candidate password with SHA-1, take the first 5 hex characters, query the HIBP range API, and check if the remaining hash suffix appears in the response. If the count is non-zero, reject the password and prompt the user to choose a different one. This adds under 100ms to your registration flow and eliminates the risk of breached passwords entering your database.