Password Strength Analyzer

What this tool does

It takes a password and tells you how many guesses it would really cost to crack, not how many it would cost according to a formula. The gap between those two numbers is usually enormous, and it is the reason this page exists.

Beyond the strength analysis, it can check whether that password appears in a known public breach without ever sending it. The two answer different questions: the first, whether it is guessable; the second, whether it is already circulating on the lists attackers use.

Everything happens in your browser. The password is not sent to any server, not stored, and not logged.

How to use it

1. Type or paste the password into the field. The analysis updates as you type.
2. Look at the bar and the two entropy figures: the real one and the textbook one.
3. Scroll to what was detected: that is the concrete reason behind the score.
4. If you want, press check on Have I Been Pwned to find out whether it has leaked.

Why the formula nearly everyone uses is wrong

The typical strength meter computes entropy like this: it counts the character types you used to infer the alphabet size, then raises that to the length of the password. By that arithmetic, Password1! has 10 characters over a 95-symbol alphabet, roughly 65 bits. Sixty-five bits sounds solid: it would mean centuries of brute force.

But Password1! does not survive a single round. It is:

• a dictionary word,
• with a capital first letter, which is what everybody does,
• a digit at the end, which is also what everybody does,
• and an exclamation mark, the symbol people reach for by default.

A dictionary attack trying common words with those three transformations finds it within a few thousand guesses. The real entropy is below 20 bits, not 65.

The flaw in the textbook formula is that it treats every character as independent and randomly chosen. In a password a human invented, they almost never are.

How it is computed here

Instead of applying a formula, the engine looks for patterns. It locates every recognizable fragment inside the password:

Each fragment is assigned a guess cost, and then the engine searches for the cheapest combination of patterns that covers the whole password. That minimum is the estimate, because an attacker is assumed to find the shortest path, not the longest.

Whatever fits no pattern is still charged at brute-force price. That is why a genuinely random password scores high: there is nothing to discount.

The gap English-only analyzers leave

Almost every tool of this kind, and the libraries behind them, ship English dictionaries. That means these passwords look structureless to them:

• holamundo2024
• mexico2026
• tequiero123
• chivas1997
• familia2020

A meter with an English dictionary recognizes none of those words, finds no pattern, and by elimination treats them as nearly random: high score, thousands of years of estimated resistance.

Reality is the opposite. Attacks against Spanish-speaking accounts have used Spanish dictionaries for decades, and those five fall in seconds. This analyzer ships Spanish lists — common words, first names, cities, football clubs and the most-leaked passwords in the region — precisely so it does not hand out that false pass.

It is the concrete reason you may see a lower score here than on other pages. This meter is not harsh: the others are not looking.

The four times, and why they do not depend only on you

The tool shows four scenarios instead of a single number, because a single number would be a lie. What decides how long a password holds is not only the password: it is how the site you use it on stores it, and you do not control that.

• Login with rate limiting (~100/hour). The normal case when someone tries the front door. Almost anything reasonable holds.
• Login without rate limiting (~10/second). A badly configured service.
• Leaked database, slow hash (~10,000/second). The site leaked, but stored passwords with properly configured bcrypt or argon2. You have time to change it.
• Leaked database, fast hash (~100 billion/second). The site stored MD5 or SHA-1 and the attacker has GPUs. This is the one that matters: it is the realistic worst case and it decides whether your password was enough.

Always read the last row. The first three are the optimistic scenario.

And the label agrees with that row. This is a deliberate difference from the usual scale: most meters award the top score from around 33 bits, a threshold designed for the rate-limited login case. Applied here it would produce a contradiction on the same screen — Mx7$tela would read as “very strong” while the table says it falls in a minute — so the scale’s cut-off points are those matching one second, one hour, one month and a century in the fast offline scenario. That is why this page is stricter than others: not pessimism, just consistency with what it measures.

What k-anonymity is, and why you can trust the check

Checking whether a password has leaked seems to require sending it, and sending a password to a third party is exactly what you must never do. The fix is a simple cryptographic trick:

1. Your browser computes the SHA-1 of the password. For example, 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8.
2. Only the first five characters are sent to the service: 5BAA6.
3. The service returns every hash in its database starting with 5BAA6 — usually several hundred — along with how many times each has appeared in breaches.
4. Your browser looks for the rest of your hash in that list, locally.

The server receives a prefix shared by thousands of different passwords. It cannot know which one was yours, whether any of the ones it returned was yours, or even whether your password was on the list at all. That is why the check is safe, and why it is optional: it only fires when you press the button.

What to do with the result

• It appears in breaches: change it now, and everywhere you reused it. It is on the lists tried first.
• Low score but not breached: it is guessable by pattern. Change it anyway.
• High score: good, but still do not reuse it across sites. An excellent password, reused, becomes every service’s problem the moment one of them leaks.

It is also what the NIST digital identity guidelines recommend: since 2017 they have advised against composition rules and forced expiry, and prioritise length and checking against breach lists.

The practical answer is usually to stop inventing them: a password manager generates a different random one per site and you only memorize the master. If you prefer to create them by hand, the password generator produces them with the browser’s cryptographic API.