Free Breach Check Tool

Data breach checker: see whether an email, a domain or a password has been exposed

Three checks live on this page, and they work in genuinely different ways. The email check asks breach databases whether an address appears in known incidents. The domain check does the same for every address at a domain you control. The password check asks whether a specific password appears in breach corpora without ever sending the password anywhere. That last distinction is the one worth reading carefully before you type anything, so it is covered first.

The password check: your password does not leave your browser

This is the question every security-conscious person asks, and it deserves a mechanical answer rather than a reassurance.

When you type into the password box, the tool waits until you have stopped typing for half a second, then does the following, entirely in your browser:

• Computes the SHA-1 hash of what you typed, using the browser’s built-in Web Crypto API (crypto.subtle.digest). Nothing has been transmitted at this point.
• Splits the resulting 40-character hex hash into the first 5 characters and the remaining 35.
• Sends only those 5 characters to the Pwned Passwords range endpoint, as a request to api.pwnedpasswords.com/range/{prefix}. It also sets the Add-Padding header, which asks the service to pad the response with decoy entries so that response size cannot be used to infer anything about your prefix.
• Receives back a list of hash suffixes and their breach counts — every leaked hash sharing that 5-character prefix, which is a large set.
• Compares your remaining 35 characters against that list locally. A match means breached, and the count comes from the matching line. No match means not found.

That design is called a k-anonymity range query. The server answering the request learns a 5-character hash prefix and nothing else. It never sees your password, never sees your full hash, and cannot tell which of the many candidates sharing that prefix you were asking about. It also has no idea whether your particular one was in the returned set, because the comparison happens on your machine after the response arrives.

Two honest caveats. First, SHA-1 is used here because that is the format the public corpus is indexed in — it is a lookup key, not a security control, and the prefix scheme is what provides the privacy. Second, the check tells you whether a password string has appeared in a breach corpus. It cannot tell you whether your account was the source. A common password will show an enormous count simply because thousands of unrelated people chose it.

Reading the password result

If the password is found, the tool shows the number of times it appeared and caps the strength rating at Weak regardless of how complex the string looks. That cap is deliberate and it is the most important behaviour on the page. A password that appears in a breach list is on the wordlist attackers try first. Its character composition is irrelevant once it is published — a fourteen-character mixed-case string with symbols that has leaked is weaker in practice than a plain unleaked passphrase.

Found counts are bucketed into severity bands so you can gauge the exposure at a glance:

Even the Low band means change it. A count of one means the exact string is in a published list, and published lists get fed into credential-stuffing tooling.

Alongside the breach lookup the tool scores composition: length is weighted most heavily, with bonuses at 8, 12 and 16 characters, plus credit for numbers and for symbols, and a penalty for recognisable sequences like 123, abc, qwerty or the word password. It is a rough heuristic to steer you toward a better replacement, not a rigorous entropy calculation, and it never overrides a breach finding.

If you want to see the mechanism work before trusting it with something real, type password. It will come back found, with a large count. Then type a freshly generated random string; it should come back clean.

The email check: what is actually queried

The email tab works differently and the page says so explicitly, with a consent step you must click through before anything is sent. There is no k-anonymity trick available for email lookups — the address is sent to our server, which queries breach databases on your behalf and returns a merged answer.

What gets queried:

The HIBP row is worth being precise about, because it is easy to misread. The tool does not ask Have I Been Pwned whether your address is breached — it uses HIBP’s public catalogue of breach records to describe incidents the other sources named. So if XposedOrNot reports a hit against a given breach, the description, date and list of exposed data classes you see come from that catalogue. Findings from multiple sources are merged and deduplicated so one incident does not appear twice under two spellings, and the result records which sources actually responded.

The corollary matters: coverage is not complete and no tool’s is. Breach databases index the incidents that have been collected and processed. Data that was stolen and never published, published somewhere the aggregators do not reach, or leaked too recently to be ingested, will not appear. A clean result means “not in these sources today”. It does not mean “never exposed”, and it should not be read as an all-clear.

Results are cached, so re-checking the same address returns the stored answer instead of re-querying the upstream services. The result panel shows when it was checked, and a re-check button forces a fresh lookup when you want current data.

Reading the email result

Each breach is listed with its name, the affected domain, the breach date, how many accounts the incident affected overall, and the data classes exposed — the field that actually drives your response. The tool highlights the categories that change what you should do next:

• Passwords exposed — change that password everywhere it was reused, starting with email and banking. Then check the password itself on this page’s password tab.
• Financial or card data — watch statements, and consider a card reissue.
• Government identifiers — the highest-friction category, because they cannot be rotated. Consider a credit freeze.
• Phone numbers and physical addresses — low urgency for account security, high relevance for phishing and SIM-swap attempts against you.
• Email only — expect targeted phishing referencing the breached service by name.

An old breach with only an email address in it needs no emergency response. A recent breach with credentials in it needs action today. Sorting your findings by that distinction is the whole job; the list is there to let you do it quickly rather than to alarm you.

A printable report can be generated from the result for attaching to a ticket or handing to a client. Producing it asks for an email address first.

The domain check

The domain tab checks a whole domain rather than a single mailbox — the question “which of my users appear in breach data” rather than “does my address appear”. It is served by a single XposedOrNot domain endpoint and requires an API key to be configured. The page checks for that capability when it loads and simply hides the tab if domain lookups are unavailable, so you are not offered a check that will fail. If the tab is not showing, that is why.

You should only run this against a domain you are responsible for. Enumerating breached accounts at somebody else’s organisation is reconnaissance, not research.

What to do with a finding

• Stop reusing the password. Reuse is what converts one company’s breach into a compromise of your accounts, through credential stuffing — automated replay of leaked pairs against unrelated sites. A unique password per site makes any single breach a contained event.
• Turn on multi-factor authentication on email first. Email is the account that can reset all the others, so it is the one attackers want. An app-based code or a hardware key is materially better than SMS, which is exposed to SIM-swap attacks.
• Prioritise by data class, not by breach age alone. A ten-year-old incident that exposed a password you still use is more urgent than last month’s incident that exposed only an email address.
• Expect the phishing to follow. Breach data is how attackers learn which services you use. A convincing message referencing a real account you really hold is the predictable next step, and it is a reason to navigate to sites yourself rather than through links.
• Do not pay a removal service. Once data is published it is copied indefinitely. Nothing can retract it; the only useful actions are rotating credentials and adding a second factor.

Common questions

Is my password logged when I use the password tab? No. It never leaves the browser tab — only the first five characters of its SHA-1 hash are transmitted, and the matching is done locally. That is verifiable from the network requests the page makes.

Is my email address logged? The address is sent to the breach databases described above in order to be checked, which is unavoidable for this kind of lookup, and the page asks you to confirm before doing it. Results are cached so that repeat checks do not re-query those services.

Why does the email check take a few seconds? It queries several external services in sequence and respects their rate limits rather than hammering them. The delay is deliberate.

My address shows no breaches — am I safe? You are not in these sources today. Aggregators do not have every incident, and recent ones take time to appear. Unique passwords and MFA protect you regardless of what any checker returns.

Should I check a password I currently use? Yes — that is the intended use, and the range-query design exists precisely so that checking a live password is safe. If it comes back found, change it before you close the tab.