Check exposure without sending the whole password
A password can be long and still be a poor choice if it has already appeared in a public breach corpus. Attackers reuse known credentials and common password lists rather than starting every attack from scratch. A breach check answers whether the supplied password is present in a particular collection; it does not measure every aspect of strength or establish whether your own account was compromised.
This tool uses Have I Been Pwned’s Pwned Passwords range API. The browser hashes the password with SHA-1, sends only the first five hexadecimal characters of that digest and receives matching hash suffixes. It then compares the complete suffix locally. The password itself and complete hash are not sent in the request, and neither appears in the exported report.
Understand the hash-prefix privacy model
The five-character prefix represents twenty bits of the hash. Many possible password hashes share that prefix. The API returns suffixes and occurrence counts for the corresponding range, and the browser determines whether one matches the remainder of your hash. The service therefore receives a partial query rather than the exact password hash.
The request includes an Add-Padding header supported by the provider, which reduces information revealed by the size of a returned range. The implementation uses a direct HTTPS request and avoids credentials and referrer information in that request. The provider still sees the connection IP and the queried prefix. This is a privacy-preserving protocol with defined disclosure, not a claim that no network information exists.
SHA-1 is used here because it is the lookup representation defined by the service. That does not make SHA-1 an appropriate password-storage algorithm. Secure password databases need purpose-designed hashing or derivation schemes. In this context, the digest is a query key for an existing corpus, not the application’s method of storing an account credential.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Interpret a match and an absence differently
A match means the exact password’s hash appears in the provider’s corpus. The returned count describes occurrences in that dataset; it does not tell how many of your accounts are affected or identify a particular person. Treat a found password as unsuitable for future use and replace it everywhere you currently reuse it.
Start with the real service’s account settings reached through a trusted bookmark or direct navigation. Use a password manager to create a unique replacement, and enable appropriate multi-factor authentication. If you suspect active compromise, review sessions and account-recovery settings as well. Changing one reused password on only one site can leave the same credential exposed elsewhere.
A “not found” result is weaker evidence. The dataset cannot include every breach or private credential collection. A short predictable password can also be absent and still be easy to guess. Use uniqueness, adequate random generation, secure recovery and multi-factor authentication independently of the corpus result.
Run the check in a trusted environment
The prefix protocol limits what the external API receives, but the page still handles the password before hashing it. A compromised browser, extension or device can defeat that local boundary. Use a trusted environment and avoid pasting an active credential into unfamiliar pages merely because they mention hashing.
This implementation does not write the password, complete digest or prefix into the downloaded report. The result records only whether a match was found, the count, provider and check time. The password remains in the input until you clear it or close the page. JavaScript cannot promise secure erasure of every memory copy, and clipboard history can retain pasted text outside the page.
If the provider is unreachable or returns an error, the tool reports that failure instead of claiming the password was absent. Repeat the check when the service is available, or use an established password manager with integrated breach checking. A network error contains no evidence about corpus membership.
A responsible follow-up focuses on the affected credential, not on identifying the people behind corpus entries. This service is designed for defensive password checking and does not reveal account ownership or return plaintext passwords associated with other hashes.
Results and sensible actions
| Result | Recommended interpretation |
|---|---|
| Found with a positive count | Replace the password wherever reused; investigate account state when warranted. |
| Not found | No corpus match returned; continue to use a unique, well-generated password. |
| Network or API failure | No valid exposure conclusion was obtained. |
| Large count | The value is common in this dataset; it does not identify your account. |
Strengths and limitations
What this is useful for
The range protocol avoids sending the password or full digest to the external service. Exact suffix matching happens locally, and the export excludes credential material. It is useful for evaluating a candidate password or confirming that a reused password should be retired.
What to keep in mind
The provider still receives a hash prefix and connection metadata. Corpus absence is not a strength guarantee, and the check does not identify which account was breached. Local secrecy depends on a trustworthy browser and page. A breach check cannot replace unique credentials and multi-factor authentication.
Common questions
Does the count refer to my email account?
No. Pwned Passwords is a password-hash corpus, and this tool does not request your email address. The count refers to the password value’s occurrences in that dataset. It does not associate a returned password hash with a named person or tell you which account used it.
Should I check a real password?
The protocol is designed to minimise disclosure to the API, but any page handling a password must still be trusted. If you prefer not to enter a live credential here, use a trusted password manager’s established breach-check feature. The tool does not require an actual account password to demonstrate its behaviour.
Exactly what reaches the external provider?
The direct request sends the first five hexadecimal characters of the SHA-1 hash, the Add-Padding request header and ordinary network metadata such as your public connection IP. The complete hash and plaintext password stay in the browser’s local processing path.
Why is a long password still found?
Length alone does not ensure uniqueness or random generation. A long quote, repeated pattern or previously leaked password can be present in a breach collection. Replace found values with independently generated passwords, rather than adding a predictable suffix to a value attackers already know.