Password entropy calculator

What this tool computes

The calculator turns a password into a single number: how many bits of uncertainty an attacker faces. It multiplies the length of your input by the base-2 logarithm of the alphabet size, then converts that bit count into a crack time at five guess rates that correspond to real attack situations. A separate button generates a random multi-word passphrase using the browser's cryptographic random number generator.

Nothing is submitted, logged, or stored. The input stays in the text field and in local variables until you close the tab.

The formula, and what each term means

Entropy in bits = length x log2(alphabet size).

The alphabet is the sum of the character sets in play: 26 lowercase letters, 26 uppercase letters, 10 digits, and 32 common symbols. A 12-character password drawn from all 94 printable characters is 12 x log2(94) = 12 x 6.55 = 78.6 bits. A 20-character passphrase of lowercase letters and hyphens is 20 x log2(27) = 20 x 4.75 = 95 bits by the same formula — but see the warning below, because that number is misleading for dictionary words.

Crack time is half the search space divided by the guess rate, which is the average time to find a value rather than the worst case. Attackers do not usually need the worst case.

Guess rate	Typical situation
100 per second	Remote login with lockout or throttling
1,000 per second	Remote login with no lockout
10,000 per second	Offline attack against a memory-hard hash
10 billion per second	Offline attack against a fast hash on one GPU
1 trillion per second	Offline attack against a fast hash on a large rig

The part the meter cannot see

This is the most important paragraph on the page. Character-class entropy assumes the password was generated by picking characters at random, uniformly, one at a time. Human-chosen passwords are not generated that way. Attackers do not enumerate all 94 characters; they start with leaked password lists, then apply mangling rules: capitalise the first letter, swap a for @, append a year or an exclamation mark.

The result is that a password like Summer2026! can score around 60 bits by the formula while falling in the first few billion guesses of a rule-based attack. The software tells you the arithmetic; it cannot tell you whether your password is on a list. Treat any password you invented yourself as weaker than the number shown, and treat the number as an upper bound.

The passphrase generator inverts the problem. Each word is drawn uniformly from a fixed list, so the honest entropy is words x log2(list length). With this tool's built-in list, five words give roughly 38 to 40 bits depending on the list size — visibly lower than the character-class figure for the same string, and far more trustworthy. The reference standard for this approach is the Electronic Frontier Foundation's Diceware word lists, which use 7,776 words for 12.9 bits per word; five EFF words is about 64 bits.

Reading the output without panicking

Bit counts are a rough currency, not a pass mark. Useful anchors:

• Under 40 bits is inside the reach of a determined offline attacker. Fine for a throwaway forum login you do not care about; not fine for anything else.
• 40 to 60 bits resists online guessing and casual offline attacks. Acceptable only where a second factor is in place.
• 60 to 80 bits is a reasonable target for a password you must type by hand into a service with rate limiting.
• 80 bits and above is comfortable against offline attack. This is where generated passphrases and manager-generated random strings live.

NIST SP 800-63B takes a different and deliberately simpler position: it requires verifiers to accept at least 64 characters, screen new passwords against breach corpora and dictionary lists, and rate-limit authentication attempts. It also advises against composition rules that force a digit and a symbol, because those rules push people toward predictable patterns like appending a 1 or an exclamation mark. That guidance is about what a service should enforce. This calculator is about what an individual password actually costs to guess, which is a related but separate question.

Building something you can remember

If you need to memorise a password rather than store it:

1. Generate the passphrase here and set the word count to five or six.
2. Type it a few times. Multi-word passphrases are long but they are typed as a rhythm, not as characters.
3. Attach it to one account only. Reuse is what turns a single breach into a cascade.
4. Store it in a password manager if you have one; memory is a fallback, not a strategy.

If a site truncates your passphrase, rejects spaces, or caps length at 16 characters, that site is the weak link. Use a manager-generated random string there and note the limitation.

What to do next

• Move email, banking, and work accounts to unique credentials first. Those accounts can reset everything else.
• Add multi-factor authentication. NIST and CISA both treat a second factor as a larger security gain than any password tweak.
• Prefer a passkey or a hardware security key over SMS codes where the service supports it.
• Check whether any account you care about appears in a known breach, and rotate those specific passwords.

What this tool cannot do

It cannot tell you whether a password has appeared in a breach. It cannot measure the strength of the hash the service uses, so the offline guess rates are scenarios rather than facts about a specific site. It cannot see that a password is two dictionary words with leetspeak substitutions, because it counts characters rather than parsing word structure. And no password configuration is immune to compromise: a compromised endpoint, a phishing page, or a malicious browser extension can capture a perfect password. Entropy reduces one specific risk. It does not eliminate the rest.

For the related decision of which second factor to use, see the MFA methods ranked explainer and the how password entropy works article.