Free Password Strength Checker

How Password Strength Is Calculated

Password strength is the answer to a simple question with a complicated answer: how many guesses would an attacker need to find your password? The naïve formula, bits of entropy = length × log₂(character-set size), gives a tidy upper bound, but it assumes the attacker is doing pure brute-force across the whole keyspace. Real attackers don't do that. They start with dictionaries of likely passwords (the rockyou.txt corpus and the top million from public breaches), apply transformation rules that mimic the substitutions humans actually make (l33t-speak, capitalising the first letter, appending 1 or ! or a four-digit year), and only fall back to brute force when the patterns don't match. A character-class meter sees P@$$w0rd99 as having all four character classes and rates it highly. A real cracker breaks it in seconds because every pattern in it is on the top-rules list.

This tool reports both numbers: naïve entropy from the character set and length, plus a separate strength score that downscores recognisable patterns (dictionary words, keyboard walks like the "zxcvbn" bottom row, repeats, sequences, dates) the way a knowledgeable attacker would. The two numbers will diverge when your password contains predictable structure, which is precisely when you most need to know.

A Short History of Password Security

Computers did not always have passwords. Before time-sharing arrived in the early 1960s, a "computer" was a single-user machine and the security model was a locked door. The mainstream story of the computer password begins at MIT's Project MAC, where Fernando Corbató's Compatible Time-Sharing System (CTSS) made one machine usable by many people at once. Once multiple users shared one filesystem, people could read each other's files. Corbató is generally credited with introducing the password prompt as the simplest possible solution: a shared secret between user and machine that proved you were entitled to the files you were asking for. The exact date is contested across secondary sources (anywhere from 1960 to 1963), but by the mid-1960s the password had become a standard feature of multi-user systems, and Multics, the more ambitious successor to CTSS that began operation in 1965, inherited and substantially extended Corbató's design.

The next foundational moment is November 1979, when Robert Morris and Ken Thompson at Bell Laboratories published "Password Security: A Case History" in Communications of the ACM. The paper is short (under five pages) and almost embarrassingly practical. Two ideas in it became the bedrock of every serious password store built afterwards. First, one-way hashing: instead of storing the password itself, the system stores a value that is easy to compute from the password but practically impossible to reverse. Second, salting: appending a random 12-bit value to each password before hashing it, so that two users with the same password produce different stored hashes and an attacker cannot precompute a single dictionary of hashes that works against everyone. Morris and Thompson noted that this multiplied the work of attacking a stolen password file by 4,096, that is, by 2¹², the size of the salt space. Every discussion of bcrypt, scrypt and argon2id in the forty years since is in some sense a footnote on Morris and Thompson.

Where the Entropy Number Comes From

The unit of measurement is the bit of entropy, and it comes from Claude Shannon's 1948 paper "A Mathematical Theory of Communication," published in two instalments in the Bell System Technical Journal. Shannon's paper invented the field of information theory and gave the world the term "bit," which Shannon credited to John Tukey. Translated to the password setting, the entropy of a password is log₂ of the number of distinct passwords that could have been produced by the same process. If a generator picks each character independently and uniformly from a set of R possible characters and produces a password of length L, then there are R^L equally likely passwords and the entropy is L × log₂(R) bits. A password chosen uniformly from the 95 printable ASCII characters with length 12 carries about 78.8 bits. Each additional bit doubles the work an attacker must do; the relationship is exponential, which is why a two-character extension to a randomly chosen password matters so much more than a single substituted character does. The catch (and it is a large catch) is that real passwords are almost never produced by uniform random sampling. People pick birthdays, partner names, dictionary words, keyboard patterns and sequences. The naïve formula is therefore an upper bound on strength, and a usually loose one.

NIST and the 2017 Paradigm Shift

For decades the dominant institutional voice on password rules in the US was NIST, the National Institute of Standards and Technology. Its earlier publications gave us the now-folk-wisdom of password policy: minimum eight characters, mix of upper and lower case, must contain a digit, must contain a symbol. That guidance was widely copied into corporate IT policy long after the security research community had concluded it was actively counterproductive. In 2017, in NIST Special Publication 800-63B, the agency formally reversed the most painful parts of the older guidance. The key changes: no more forced periodic password changes unless there is evidence the password has been compromised. Studies showed that mandatory ninety-day resets cause users to pick weaker, more predictable passwords (capitalising a letter and adding 1 is the canonical example), defeating the whole point of the rotation. No more mandatory composition rules: verifiers should not require particular character classes, because they push users toward predictable substitutions like P@ssw0rd! rather than toward stronger passwords. Length is the dominant factor. Check passwords against known-breached lists, the single most consequential operational change, and the reason the Have I Been Pwned Pwned Passwords corpus exists in the form it does. NIST published the final version of the next major revision, SP 800-63B-4, on 31 July 2025, strengthening the 2017 direction and extending it to phishing-resistant authenticators (including syncable authenticators of the kind used by passkeys).

zxcvbn, Why Modern Meters Look Alike

The reason most serious password strength meters look the same on the surface is that most are running, or are inspired by, the same piece of code. That code is zxcvbn, an open-source pattern-aware estimator originally released by Daniel Lowe Wheeler at Dropbox in April 2012 and later formalised in a peer-reviewed paper at the 25th USENIX Security Symposium in August 2016. The name is itself a joke: it is the bottom row of a QWERTY keyboard, the kind of password the library is designed to recognise and downscore. zxcvbn detects dictionary matches against about 30,000 common passwords plus US-census names and surnames, popular English words, Wikipedia tokens and US TV/film titles; leet-speak substitutions (so p@ssw0rd is treated as password); keyboard walks like qwertyuiop and asdfghjkl; repeats (aaaa, abcabcabc); sequences (abcdef, 12345); and dates within plausible human ranges. It then computes the minimum-guess decomposition (the cheapest combination of recognised patterns that explains the entire password) and multiplies the per-pattern guess counts to estimate the total guesses an informed attacker would need. The library is browser-deployable but not weightless: bundled and minified, zxcvbn is about 400 KB gzipped, most of which is the dictionaries themselves. That is small enough for a single-purpose page like this one but heavy enough that the maintainers explicitly warn against bundling it into every page of a general-purpose web app.

What "Crack Time" Really Means

Every strength meter shows a "time to crack" estimate, including this one. The honest answer is that this is one of the easiest numbers to report and one of the hardest numbers to defend, because it depends almost entirely on assumptions the user cannot see. The base assumption is the attacker's guesses per second. That number is not one number; it is a spread of about ten orders of magnitude depending on what the attacker has stolen and what hashing scheme the defender used. Unsalted MD5 or SHA-1: a single NVIDIA RTX 4090, a consumer-grade graphics card from 2022, can compute on the order of 150-165 billion MD5 hashes per second using the standard cracking tool hashcat. Eight such cards in a single rig push the number past a trillion per second; cloud-rented multi-GPU instances on AWS or Google Cloud cost in the low single digits to low tens of dollars per hour. For any password store that uses fast unsalted hashing, modest passwords are essentially defenceless. bcrypt at sensible cost factors: bcrypt was designed in 1999 specifically to be slow on parallel hardware. At cost factor 12 (the rough industry default), a single GPU can do hundreds to low thousands of guesses per second per core, not tens of billions. The crack time against bcrypt is millions of times longer than against MD5. scrypt and argon2id: these add memory-hardness, every guess requires not just CPU cycles but a substantial amount of RAM, which makes parallelisation on GPUs and ASICs prohibitively expensive at sensible parameters. Argon2id is the current OWASP recommendation and the winner of the 2015 Password Hashing Competition.

A meter that quotes a single crack time is, at best, telling you the answer for the worst-case scenario in which the attacker has stolen a fast-hash database. That is also the only honest default for a generic strength meter to show. A user cannot know in advance whether the next service that gets breached will have used MD5 or argon2id. The 10 billion guesses per second this tool assumes is in the same ballpark as the worst-case fast-hash scenario, an order of magnitude below the absolute peak of a top-tier rig but representative of what a determined attacker can rent for a small budget.

The 2009 RockYou Breach and Why Reuse Kills

RockYou, a maker of Facebook and MySpace add-ons, stored roughly 32 million user passwords in plaintext. In December 2009 an attacker exploited a SQL injection vulnerability and exfiltrated the entire user database. The plaintext passwords were posted publicly. The de-duplicated wordlist, rockyou.txt, with about 14 million unique passwords, is now the default starting dictionary for almost every password-cracking tool in the world. Every password that appeared in that breach is, for practical purposes, instantly crackable forever, no matter how strong its naïve entropy looked. This is also why password reuse is the single largest practical risk to most users' accounts. A user who reuses the same password across fifty sites needs only one of those sites to leak; a user with a unique password per service needs all fifty to leak. The reference dataset for known-breached passwords is Have I Been Pwned, launched by Australian security researcher Troy Hunt on 4 December 2013. The Pwned Passwords subsystem indexes well over a billion unique compromised SHA-1 password hashes, with roughly 1.3 billion newly seen passwords added in the November 2025 update alone.

k-Anonymity: Checking a Password Without Revealing It

The clever part of Pwned Passwords is the API design, which solves what was historically a serious privacy problem: how do you let a third party check whether a password is in a known-breached list without sending them your password? The naïve approach (POST your password to the service) recreates the very problem the user was trying to avoid. The k-anonymity solution, designed by Junade Ali at Cloudflare in 2018, works as follows: the client computes the SHA-1 hash of the password; the client sends only the first five hex characters of that hash (a prefix that identifies one of about a million possible buckets); the server returns all of the suffixes for hashes that begin with that prefix, typically a few hundred matches; the client checks locally whether the full hash is in the returned list. The server never learns which password the user is checking; it only learns one of about a million prefix buckets, which on its own identifies hundreds of plausible passwords. This is the same statistical-anonymity model used to anonymise medical records: each query is statistically indistinguishable from at least k others. Browser password managers, enterprise identity systems and serious strength meters use the same prefix-and-suffix protocol.

Use a Password Manager

The argument for password managers is not that they make you immune to breach (they don't, and several have themselves been breached), but that they let you have a unique password on every service, so the next breach of a service you use does not also compromise your bank account. KeePass, the oldest of the widely-used managers, was first released by Dominik Reichl in November 2003. 1Password, by AgileBits, shipped its first version in 2006. Bitwarden, the dominant open-source cloud-syncing manager, launched in August 2016. The modern recommendation (memorise one strong master passphrase, let the manager generate everything else) is shared across NIST, OWASP, EFF and essentially every serious security organisation. The single master passphrase becomes the only password you need to remember well; the manager handles the rest, generates random 20-character strings per service, fills them in for you, and warns you when you reuse one. If you take a single piece of advice from this entire page, take that one.

Passphrases for the Things You Have to Remember

For passwords you genuinely have to memorise (your password-manager master passphrase, your computer login, your phone unlock), passphrases beat passwords. XKCD #936 ("Password Strength"), published 10 August 2011, made the case to a wide audience: correct horse battery staple is four random English words, easier for a human to memorise than Tr0ub4dor&3 and orders of magnitude harder for a computer to guess. The mathematics is straightforward: if you draw words uniformly from a list of size N, each word contributes log₂(N) bits of entropy. The Diceware system, invented by Arnold Reinhold in 1995 and originally distributed on the Cypherpunks mailing list, formalises this with a 7,776-word list (so each word is selected by five rolls of a six-sided die). Each Diceware word contributes about 12.9 bits of entropy; a six-word passphrase carries roughly 77 bits, which Reinhold has recommended as the floor for everyday use. The Electronic Frontier Foundation released its own improved long word list in July 2016, with words chosen for memorability and length (averaging seven characters versus Diceware's ~4.3). The security of the EFF list and the original Diceware list is identical at the same word count; the EFF list is just easier to live with. The crucial caveat is that the words must be actually random, picked by dice or a real RNG. A passphrase taken from a song lyric, a film quote or a famous Bible verse is in every dictionary attacker's wordlist and is no stronger than a single dictionary word.

Passkeys: The Long-Term Replacement

The longer-term direction of travel is that high-value accounts are leaving the password world altogether. On 5 May 2022, Apple, Google and Microsoft jointly announced expanded support for the FIDO standard and a passkey-based passwordless sign-in flow that syncs across devices and platforms. A passkey is a public-key credential held on the user's device; the private key never leaves the device, the public key is registered with the relying party, and authentication is a cryptographic challenge-response that is immune to phishing in a way passwords categorically are not. The FIDO Alliance reported in early 2025 that more than fifteen billion online accounts could already use passkeys, and that adoption had doubled in 2024 alone. Google reported in late 2024 that more than 800 million Google accounts had at least one passkey configured, with sign-in success rates up around 30% and sign-in speed up roughly 20% on average. Major platforms (Amazon, Apple iCloud Keychain, Google Password Manager, Microsoft Authenticator) all support synced passkeys today. Passkeys are not yet a complete replacement (many smaller sites do not support them, and the recovery story still varies by platform), but for any account that supports them, increasingly including email, social media, banking and major SaaS platforms, a passkey is the right answer and a strong password is a reasonable second choice.

Privacy: Why a Browser-Only Checker Matters

Every "test your password" tool that sends the password to a server is, by construction, a risk. That includes most of the historical password meters that ran their analysis server-side. The right pattern for a modern tool, the pattern this page follows, is that the password never leaves your browser. The strength estimator runs locally; the entropy figure is computed locally; the suggestions are generated locally. Nothing is logged, nothing is stored, nothing crosses the network. That is the privacy argument worth making plainly. It is the only argument for a password tool that genuinely distinguishes a trustworthy implementation from a careless one. A user who does not control the source code of a strength meter cannot be sure their password is not being logged, but they can at least look at network activity in their browser's developer tools, and a tool that makes no network requests when the user types is verifiable in seconds. That makes "runs entirely in your browser" not just a marketing claim but a falsifiable one, which is a much better species of claim. Even with that guarantee, the safest practice is still to test a structurally similar password rather than the actual one (same length, same character mix, same patterns) for any password you use today.

Seven Takeaways

1. Length dominates. Twelve characters is the practical minimum; sixteen or more is the right floor for important accounts. Each additional character roughly doubles the brute-force attack surface.
2. Composition rules are theatre. A long passphrase beats a short string of mixed-case-plus-digits-plus-symbols on every honest measure.
3. Reuse is the dominant attack surface. A single leaked password becomes a key to every service that shares it.
4. A password manager is the answer for most people. Memorise one strong passphrase, let the manager handle the rest.
5. Passkeys, where supported, are better than any password. They are phishing-resistant by design and sync across the user's devices.
6. A strength meter is an estimator, not a guarantee. It assumes a particular attack model; real attackers may do better against pattern-laden passwords than the meter's number suggests.
7. Trust the meter's privacy claim only if you can verify it. A meter that runs entirely in the browser can be verified by any user with the developer tools open. A meter that posts to a server cannot.

Frequently Asked Questions

Is my password sent to a server?

No. All analysis happens locally in your browser via JavaScript. Your password never crosses the network, never lands in a server log, never enters a database. You can verify by opening DevTools' Network tab while you type: there are no outbound requests. Even with that guarantee, the safest habit for any password you actually use is to test a structurally similar one (same length, same character mix, same patterns) rather than the live password.

How many characters should my password be?

At least 12 characters for most accounts, 16+ for important ones (banking, primary email, password-manager master passphrase). Length matters more than character variety because each additional character roughly doubles the brute-force attack surface. NIST's 2017 guidance and its 2025 update both name length as the dominant factor; mandatory mixed-case-plus-digits-plus-symbols rules are explicitly discouraged because they push users toward predictable patterns like P@ssw0rd!.

Is a passphrase better than a random password?

For passwords you have to memorise, yes. A six-word Diceware-style passphrase (correct horse battery staple style, four to six random English words) carries roughly 77 bits of entropy and is dramatically easier to remember than a 12-character random string. The crucial caveat is that the words must be actually random, picked by dice or a real RNG. A passphrase from a song lyric, film quote or famous text is in every dictionary attacker's wordlist and is no stronger than a single dictionary word.

Why does this tool show a different score than another meter?

Because different meters use different models. A naïve character-class meter sees P@$$w0rd99 as having all four classes and rates it highly; a pattern-aware meter (modelled on Dropbox's open-source zxcvbn library) recognises the dictionary word, the leet-speak substitutions and the trailing-digit pattern, and rates it as breakable in seconds. This tool reports both: naïve entropy from length and character set, plus a pattern-aware score that downscores recognisable structures. The two will diverge when your password contains predictable patterns, which is exactly when the warning is most useful.

Should I trust the crack-time estimate?

As a worst-case ballpark, yes. The 10 billion guesses per second this tool assumes is in the same order of magnitude as a determined attacker with a single recent GPU cracking unsalted MD5 or SHA-1 hashes (an RTX 4090 can do 150-165 billion MD5/sec; a small rig pushes that into the trillions). For services that use proper modern hashing (bcrypt at cost factor 12, scrypt, argon2id), the actual attack would be millions of times slower, but you have no way to know in advance which hashing scheme the next breached service used, so planning for the worst case is prudent.

What about checking if my password has been in a breach?

For that, use Have I Been Pwned's Pwned Passwords service (haveibeenpwned.com/Passwords). It uses a k-anonymity model designed by Junade Ali at Cloudflare in 2018: your browser computes the SHA-1 of your password, sends only the first five hex characters, and the server returns all matching suffixes; your full password and full hash never cross the network. The corpus contains over a billion known-breached SHA-1 hashes. Browser password managers (1Password's Watchtower, Bitwarden's data-breach report, Chrome's Password Checkup) integrate the same API automatically.

Related Tools