Password Strength Checker
Goes beyond "has a number and a symbol" — detects common passwords, dictionary words, keyboard walks and dates, then estimates real crack time under three attack scenarios. Nothing you type ever leaves your browser.
How to Read Your Result
Features
The Problem With Checkbox-Style Password Meters
Type "Password1!" into most strength meters and you'll get a green bar and a "Strong" label. It has uppercase, lowercase, a digit, a symbol, and clears the usual length minimum — every box checked. It is also, functionally, one of the first passwords any real attacker tries, because "capitalize the first letter, add a digit, add an exclamation mark" is such a common human pattern that cracking wordlists build it in as a standard rule. Requirement checklists were designed to nudge people toward a larger character pool, not to measure whether the specific result is actually unpredictable — and those are two very different things. This checker is built around the second question instead of the first.
Raw Entropy vs. What an Attacker Would Actually Try
The starting point is still the standard formula — length × log₂(pool size) — which gives a theoretical ceiling based on how many characters could occupy each position. But that ceiling assumes true randomness, and most human-created passwords aren't random at all. So this tool scans for the specific structures real cracking tools are built around: known common passwords, dictionary words (plain or with substitutions), keyboard-adjacent runs, ascending or descending sequences, short repeating blocks, and embedded years. Whenever one turns up, the displayed "effective entropy" is recalculated as if the attacker used that shortcut instead of guessing blind — and the lower of the two numbers is what actually gets shown as your score, because a password is only as strong as its weakest realistic attack path.
Reading the Weaknesses List
Each flagged item names the exact substring responsible and explains, in plain terms, why it matters — "sunshine" being a dictionary word, "qwerty" being a keyboard row, "1990" reading as a plausible birth year. This is deliberately more specific than a generic "weak password" verdict, because the fix is different for each one: a dictionary word calls for replacing that segment entirely, while a length shortfall just calls for typing more characters. If you'd rather start over with something engineered to avoid all of these patterns from the outset, the Password Generator builds both fully random passwords and memorable passphrases that won't trip any of these detectors.
The Personal-Info Check Targets a Specific, Common Mistake
Generic wordlists and pattern rules only catch part of how real passwords get built — plenty of people anchor a password to something personal instead: a first name, a username they already use elsewhere, a birth year. None of that shows up in a public common-password list or a dictionary scan, because it's specific to one person rather than a pattern shared across millions of leaked accounts. That's exactly why this check is separate and optional rather than folded into the automatic scan: it needs you to supply the personal details yourself before it has anything to compare against.
The reason it matters goes beyond random guessing. A targeted attacker — someone who already knows or can look up a target's name, username, or approximate age — doesn't need to brute-force anything if the password is simply that information rearranged slightly. Flagging "Jordan1995" as weak isn't about its raw character variety, which is genuinely decent; it's about recognizing that this exact structure is the very first thing a targeted guess would try. Leaving the fields blank skips the check entirely and costs nothing else — the rest of the analysis runs exactly the same either way.
Why Three Different Crack-Time Numbers
A single crack-time figure invites a false sense of precision, because the real number depends enormously on how the password is being attacked. A login form with reasonable rate-limiting might only allow a couple of guesses a minute before locking the account — under that model, even a moderately weak password can hold up for a long time. But if an attacker has stolen a database of password hashes and is working offline with no rate limit, the picture changes entirely: a slow, deliberately expensive hashing algorithm like bcrypt might limit them to a few thousand guesses per second, while an older fast hash cracked on modern GPU hardware can exceed ten billion guesses per second. Showing all three side by side makes clear that password strength and the service's own security practices both matter — a password that would take centuries against a slow hash could fall in hours against a fast one.
Where People Actually Get This Wrong
- Substituting characters in a common word: "P@ssw0rd!" looks different from "password" but normalizes right back to it — wordlist tools check these substitutions as a default rule, not an edge case.
- Building a password around a keyboard shape: "1qaz2wsx" traces a simple zigzag on the keyboard and shows up on breach lists constantly, despite looking random at a glance.
- Using a name plus a year: "Jordan1995" mixes letters and digits but is exactly the kind of name-plus-date structure that targeted attacks (and the personal-info check here) are built to catch.
- Assuming length alone is enough: "aaaaaaaaaaaaaaaa" is sixteen characters long and still trivially weak — repetition collapses entropy regardless of length.
- Trusting a green checkmark from a different site's meter: if that meter only checks character types, it will happily approve several of the examples above.
Where This Tool Reaches Its Limits
A strong score here means the password resists every pattern this checker knows to look for — it can't promise protection against phishing pages that simply ask you to type your password in, malware logging your keystrokes, or reusing the same strong password across accounts where one breach compromises all of them. This tool also doesn't check a live breach database over the network by design — doing so would mean transmitting your password somewhere, which conflicts with the fully local, private approach used across every ToollyX security tool. If you're managing passwords for a service that stores them server-side, they should always be hashed with something like Bcrypt, never kept as plain text, and never compared using reversible encryption where a hash would do.