Password Strength Calculator

Understanding the Password Strength Calculator

A password strength checker scores composition and estimates entropy from character variety and length. It's worth stating plainly what this measures: it counts character types, not guessability, and those two diverge enough that a password scoring highly here can fall to a real attack in seconds.

How it actually works

Enter a password. The tool awards points for length at 8 and 12 characters and for containing lowercase, uppercase, digits, and symbols, then estimates entropy as length multiplied by the base-2 logarithm of the character pool. The string Tr0ub4dor&3 scores 5 of 6 and reports 72.1 bits.

The deeper context most people miss

That table is the whole point. The entropy formula assumes every character was chosen uniformly at random from the pool, which is true for generated passwords and false for anything a human invented. A real attacker guesses in order of likelihood, so predictable patterns fall long before their nominal bit count suggests.

Why composition rules were abandoned

For years, guidance required a mix of uppercase, lowercase, digits, and symbols along with periodic mandatory changes, and the evidence eventually showed both practices were counterproductive. Composition requirements push people toward a small set of predictable transformations: capitalising the first letter, appending a digit and an exclamation mark, substituting zero for o and three for e. Attackers know these transformations and apply them as rules during cracking, so a password meeting every composition requirement can sit within the first few million guesses. Mandatory rotation made things worse, since people responded with incremental changes such as appending a counter, and research found rotated passwords were frequently predictable from their predecessors. The US National Institute of Standards and Technology revised its digital identity guidelines in SP 800-63B to reflect this, recommending against imposed composition rules and against arbitrary periodic expiry, and instead requiring a minimum length, allowing much longer passwords including spaces and all printable characters, and screening candidate passwords against lists of known-breached and commonly used passwords. That last measure is the substantive one: checking whether a password already appears in breach corpora catches the passwords that actually fall, which composition scoring does not. The UK National Cyber Security Centre reached similar conclusions independently. Any strength meter still scoring purely on character variety reflects the older model.

A worked example: why the entropy figure misleads

The tool reports 72.1 bits for Tr0ub4dor&3, calculated as 11 characters times log2 of a 94-character pool. Seventy-two bits would take an infeasibly long time to brute-force. But nobody brute-forces. An attacker with a stolen password hash runs a dictionary of common words and applies mangling rules: capitalise, substitute characters, append digits and symbols. Troubadour is a dictionary word, the substitutions are the standard ones, and the suffix is a common pattern, so the password sits within a search space of perhaps a few billion rather than 2 to the 72, which modern hardware exhausts quickly. The XKCD comic that popularised this example made exactly that point. By contrast, four random common words concatenated draw from a list of perhaps 8,000 words, giving roughly 13 bits per word and around 52 bits total, and critically that estimate holds because the words really were chosen at random. Fifty-two genuine bits beats seventy-two assumed ones. The practical measure that matters is guess number: how many attempts before this password is tried. Strength estimators built around that idea, notably zxcvbn, model dictionaries, keyboard patterns, dates, and common substitutions, and produce estimates far closer to reality than a composition score. They are also what a well-built signup form should use.

Deciding how to actually manage passwords

The realistic answer for most people is a password manager, and the reasoning is arithmetic rather than preference. Security requires that passwords be long, random, and unique per site, and no human can remember dozens of long random strings, so any approach relying on memory forces reuse or predictability. A manager generates and stores them, requiring you to remember exactly one strong passphrase. The common objection is that it creates a single point of failure, which is true and is still substantially better than the alternative it replaces, since reputable managers encrypt locally with the master password never leaving the device, and the realistic threat for most people is credential stuffing after a site breach rather than a targeted attack on their vault. Reuse is the specific danger: when one site is breached, attackers try the same credentials everywhere, and this is how most account takeovers happen. Beyond the manager, multi-factor authentication is the single largest improvement available, and it matters more than password strength for most accounts, since it defeats credential stuffing entirely. App-based authenticators and hardware keys are stronger than SMS, which is vulnerable to SIM swapping, though SMS is far better than nothing. Passkeys, based on public-key cryptography, remove the shared secret altogether and are increasingly supported, and they represent the direction the whole problem is moving.

What happens when a password is stolen

Understanding the attack explains which defences matter. Passwords are stored as hashes rather than plaintext, and the security of a breached database depends entirely on how they were hashed. Fast general-purpose hashes including MD5 and SHA-1, still found in old systems, can be tested at enormous rates on commodity GPU hardware, so a breach of a site using them exposes most passwords quickly. Purpose-built password hashing functions including bcrypt, scrypt, and Argon2 are deliberately slow and memory-intensive, reducing testing rates by orders of magnitude, and Argon2 is the current recommendation. Salting, adding a unique random value per password before hashing, prevents precomputed rainbow tables and ensures identical passwords hash differently, and its absence is a serious flaw. Peppering, a secret value stored separately from the database, adds another layer. None of this is visible to a user choosing a password, which is why individual password strength matters less than people assume relative to the site's own practices, and why unique passwords matter so much: you cannot control how a site stores yours, so the defence is ensuring a breach at one site does not compromise others. Services that check whether an address or password appears in known breaches are genuinely useful, and being notified that a credential has appeared in a corpus is a clear signal to change it everywhere it was used.

Variations: passphrases, generated passwords, and length requirements

Randomly generated passwords from a manager, typically 16 to 20 characters across a full character set, provide entropy well above any plausible attack and require no memorisation. Passphrases built from randomly selected words suit the few passwords that must be memorised, principally a password manager master password and device login, and methods including diceware select words with genuine randomness rather than letting a person choose them, which is essential since human word choice is far from random. Length matters more than character variety, since each additional character multiplies the search space, and a long lowercase passphrase beats a short mixed-case string comfortably. Minimum length requirements have risen, with 8 characters now widely considered inadequate and 12 to 16 a more reasonable floor for anything important. Maximum length limits, still imposed by some sites, are a sign of poor practice since properly hashed passwords are fixed-length regardless of input. Character restrictions that forbid spaces or particular symbols similarly suggest the password is not being hashed correctly. Security questions are effectively weak secondary passwords whose answers are frequently public, and treating them as additional random strings stored in a manager is better than answering them honestly.

Choosing and managing passwords well

Use a password manager and generate long random passwords for every account, since uniqueness matters more than any individual password's strength and no one can memorise dozens of random strings. Enable multi-factor authentication wherever available, which is the single largest improvement and defeats credential stuffing entirely, preferring app-based authenticators or hardware keys over SMS. Use a randomly generated passphrase for the few passwords you must memorise, selecting words by a random method rather than choosing them yourself. Prioritise length over character variety, since each extra character multiplies the search space while composition tricks are exactly what attackers model. Ignore advice to rotate passwords periodically without cause, which NIST now recommends against because it drives predictable incremental changes. Check whether your credentials appear in known breach corpora and change anything that does everywhere it was used. And treat a high score from any composition-based meter, including this one, as a statement about character variety rather than about resistance to a real attack.

What people get wrong

• Reading a high composition score as real security, when the entropy formula assumes uniform random selection and human-chosen passwords are guessed in order of likelihood.
• Relying on character substitutions such as zero for o and three for e, which attackers apply as standard mangling rules during dictionary cracking.
• Rotating passwords on a schedule without evidence of compromise, which NIST now recommends against since it drives predictable incremental changes such as appended counters.
• Reusing a strong password across sites, when credential stuffing after a breach elsewhere is how most account takeovers actually happen.

Where the math comes from

Entropy in bits = Password Length × log₂(Character Pool Size), where the pool adds 26 for lowercase, 26 for uppercase, 10 for digits, and 32 for symbols. This assumes every character was selected uniformly at random from the pool, which holds for generated passwords and not for human-chosen ones, so the figure substantially overstates resistance for anything containing dictionary words, names, dates, or common substitution patterns.

Questions and answers

Related calculators

Trash Bag Size · Laundry Load · Stair Stringer · Conversion Rate · Color Brightness