A password breach check can tell you whether a password's hash appears in the corpus returned by a particular service. A match is a strong reason to replace the password wherever it is used. No match is narrower evidence: the service did not return a matching entry from its current corpus.
The check does not prove that a password is unpredictable, unique to an account or known only to you. Use it alongside unique password generation, a password manager and suitable account protection. Keep breach-corpus evidence separate from a password-strength estimate.
Understand the range-query flow
The password breach checker computes the password's SHA-1 hash locally, sends the first five hexadecimal characters to the Pwned Passwords range endpoint and receives candidate suffixes with occurrence counts. It compares the remaining suffix locally.
The plaintext password and complete hash are not sent by this implementation. The service still sees the prefix, connection IP and ordinary request metadata. Prefix queries reduce what is disclosed compared with sending the password, but they should not be described as revealing nothing about the query.
The request includes the service's padding option. Padded responses include entries intended to reduce information available from response-size differences. The client treats zero-count padding entries appropriately and uses a positive matching count as the corpus finding.
Know why SHA-1 appears here
SHA-1 is used as the lookup representation defined by this password corpus API. That does not make a single SHA-1 digest suitable for storing account passwords. Password storage needs a dedicated design with salts and work factors appropriate to the service.
A hash prefix is not encryption. The protocol avoids sending the complete lookup value, while the service returns a range of candidate suffixes. An observer's knowledge and the password's predictability still matter to privacy analysis.
Do not copy this lookup protocol into an authentication database and assume it provides secure password storage. The corpus check answers whether a candidate appears in a known dataset; login verification is a different function with different requirements.
| Result | What it supports | Practical response |
|---|---|---|
| Positive matching count | The service reports this password hash in its corpus | Replace the password wherever reused |
| No matching entry | No match returned from this corpus query | Still require uniqueness and suitable generation |
| Timeout or service error | The check did not complete | Retry appropriately; do not label the password clear |
| Padded zero-count entry | Response padding, not a positive breach occurrence | Do not treat zero as a match finding |
| Large occurrence count | Many reported corpus occurrences | Do not infer which of your accounts was affected |
Respond to a positive match
Replace the password on every account where it is used, starting with important email, financial and administrative accounts. Generate a different password for each service and store it in a password manager. A small variation of the old password can preserve a predictable pattern.
Use each service's normal password-change flow and review available account security information. If you suspect account access, inspect active sessions and recovery settings and use the service's supported sign-out or recovery controls. A corpus match alone does not identify a specific account compromise.
Enable suitable multifactor authentication or passkeys where supported. These measures address risks beyond password reuse, though their recovery paths also need attention. Keep recovery codes and account recovery methods in a secure, usable place.
Understand why no match is not a clean bill of health
The corpus cannot contain every leaked or guessed password. A newly exposed password may not be represented, and a weak password can be easy to guess without ever appearing in the dataset. Absence therefore does not establish secrecy or strength.
A password can also be reused across your own accounts without appearing in the corpus. Reuse creates a risk when one service is compromised later. The breach check cannot discover all your accounts or verify that each uses a different secret.
For a newly generated long random password, a no-match result is one useful check, but the generation and storage process provide separate evidence. Keep those steps in the workflow instead of treating one result badge as the whole decision.
Replace a reused password without losing account access
Suppose a password used for email and two shopping accounts returns a match. First confirm you can access the password manager and account recovery methods. Change the email account through its official site, save the new unique password and verify a fresh login.
Then change the other accounts to different generated passwords. Check saved browser credentials and devices that may still hold the old value. Keep a private checklist of completed changes without writing the actual passwords into an ordinary document.
Review active sessions where the services provide that control. A password change may not revoke every existing session automatically. Follow the account's documented security flow rather than assuming the old session tokens disappeared.
Finally remove obsolete saved credentials and ensure recovery information remains correct. The goal is a durable account workflow, not merely obtaining a no-match result for another password that will be reused everywhere.
Check the deployed data flow
This implementation sends the range request directly from the browser to the documented service with omitted credentials and no referrer information. The exported report excludes the password, full hash and prefix. It records the finding, count, source and check time.
Those properties should remain true if the application is modified. Avoid logging password fields, request prefixes or complete hashes through analytics or error reporting. A frontend that performs a privacy-preserving query but records the input elsewhere defeats the intended data flow.
Use a trusted browser environment for sensitive input. Local hashing does not protect against a compromised device or extension that can observe the password before hashing. The protocol reduces disclosure to the lookup service; it does not eliminate every endpoint risk.
Use the check appropriately in account creation
A service can reject known compromised password choices and explain how to choose a unique alternative. Keep the message practical and avoid revealing unnecessary details about the corpus. Apply request limits and handle service availability without silently converting errors into successful checks.
Do not require users to disclose a password to an unrelated diagnostic as a condition for support. Integrate checks through a documented, reviewed flow where appropriate. The user should understand where the query goes and what information is transmitted.
Keep password acceptance rules aligned with the authentication system's current guidance. Excessive character restrictions can make password managers harder to use without addressing reuse. A breach check should complement sound password handling rather than become another arbitrary complexity rule.
Do not overinterpret occurrence counts
The returned count reflects the service's corpus records. It is not a count of your accounts, a timeline of your personal exposure or proof that your current account was breached. A common password can appear many times because many people chose it.
A low count is not a reason to keep the password. Once a password is known in a breach corpus, uniqueness and secrecy assumptions are weakened. Replace it rather than ranking a small match as safe enough.
Keep the source and date with a report because the corpus can change. A past no-match result does not promise that a later query will remain negative. The account's ongoing protection should not depend on a one-time lookup.
Frequently asked questions
Does the tool send my password to the service?
This implementation hashes it locally and sends only the first five hexadecimal hash characters. The full hash comparison happens in the browser. The service still receives connection metadata and the prefix, so the protocol reduces disclosure without making the request completely information-free.
Does a match prove my account was hacked?
No. It proves the service returned a matching password-hash entry with a positive count. The same password may have been used by others. Replace it and review account security, but do not infer a specific account incident without additional evidence.
Is a password safe if no match appears?
No-match means only that this query found no matching corpus entry. The password can still be weak, reused or newly exposed. Use unique generated passwords and appropriate account protection regardless of the result.
Why does the API use SHA-1?
It is the corpus lookup format. It is not a recommendation for password storage or general collision-resistant integrity design. Keep the API's indexing protocol separate from the authentication system that stores and verifies user passwords.
What should happen if the service is unavailable?
Show that the check could not complete and provide a reasonable retry path. Do not display not found when the request timed out or returned an error. Missing evidence must remain distinguishable from a completed negative result.
Should I make a small change to the old password?
Generate a new independent password instead. Predictable variations can be guessed and may preserve reuse habits. Store the new value in a password manager and verify recovery access before replacing important account credentials.
What can I share from the report?
The exported finding omits the secret and lookup material. Review it before sharing and include only the result needed for the discussion. Never paste the password itself into a support ticket to demonstrate that a breach check matched.