Password Entropy Calculator

Entropy is the only number that matters

"Use a strong password" is bad advice. The actually-useful question is: how many bits of entropy? Entropy is the log2 of the search space — basically, how many guesses an attacker needs on average. More bits = exponentially harder to crack.

Two strategies that actually work

Diceware passphrases — 5+ random dictionary words separated by spaces. Each word from a list of ~7,776 contributes about 12.9 bits. Six words ≈ 77 bits, easy to memorize.

Random character strings — minimum 14 chars from full ASCII (a-z, A-Z, 0-9, symbols). 14 chars × log2(95) ≈ 92 bits. Use a password manager — you won't memorize it.

What entropy actually means

Password entropy is a measure of how many guesses an attacker would have to try before finding your password. The unit is bits — each bit doubles the number of possible values. A password with 40 bits of entropy has about a trillion possible values. A password with 80 bits of entropy has about a septillion. The relevant question is: how many guesses per second can an attacker make, and how many total guesses can they afford before it stops being worth their time?

Modern password-cracking hardware — specifically, GPU rigs and dedicated ASICs — can compute billions to trillions of hash guesses per second against a stolen database. Cloud-based cracking services rent similar capability by the hour. The economics of who gets attacked and how hard depend on what the attacker gains from cracking the password. A random person's forum account isn't worth much effort. A crypto wallet with a million dollars is worth a lot.

How the calculation works

The calculator uses the standard entropy formula: log2(character_pool_size) × password_length. If you use only lowercase letters (26 characters) and your password is 10 characters long, that's log2(26) × 10 = about 47 bits. If you use lowercase, uppercase, digits, and symbols (about 94 characters), 10 characters gives you about 65 bits.

This assumes the password is truly random within the character set. That's the important caveat. If your "random" password is actually a dictionary word with some substitutions ("P@ssw0rd!"), the effective entropy is much lower than the formula suggests, because attackers try dictionary-based patterns first. The formula gives an upper bound, not a guaranteed lower bound.

What the resulting time-to-crack numbers mean

The time-to-crack estimate assumes an attacker with realistic modern hardware and a stolen password database. It doesn't apply to online guessing — most services rate-limit login attempts, so an attacker guessing against a live login form can only try a handful of passwords per minute. The relevant threat is offline cracking: an attacker who steals the hashed password database from a compromised service and runs cracking software against it.

Rough calibration for offline cracking speeds against SHA-256 (a common but bad choice for password storage) in 2026:

• Consumer GPU rig: 5-10 billion guesses/second
• Dedicated cracking rig with 8 GPUs: 40-80 billion guesses/second
• Cloud-rented cluster for a few hours: hundreds of billions to trillions/second
• Nation-state resources: essentially unlimited within reason

Against modern password hashing functions (Argon2, bcrypt, scrypt), these numbers are much lower — often tens of thousands or hundreds of thousands per second rather than billions. This is intentional; the whole point of modern password hashing is to be slow. If a service is using proper password hashing, even relatively short passwords remain hard to crack.

The tool assumes an intermediate threat model — better than raw SHA-256 but not as good as Argon2 — as a middle-ground estimate. Your actual security depends on what the service you're using does with your password.

What actually makes a good password

Length beats complexity, usually

Doubling the length of a password adds many more bits of entropy than making it more complex. A 20-character lowercase-only password (about 94 bits) is harder to crack than a 12-character password using every character class (about 79 bits). The complexity requirements that many sites still impose ("must contain uppercase, lowercase, number, and special character") are a leftover from an earlier era and often hurt more than they help by pushing users toward "Password1!" patterns.

Randomness beats memorability

A truly random password chosen by a password manager is much stronger than any password you invent yourself, because human-chosen passwords cluster around patterns that attackers know about. Common substitutions (@ for a, 3 for E, ! at the end), keyboard patterns (qwerty, 1234), sports teams, family names, birthdays — these are the first things cracking dictionaries include.

Passphrases work if you generate them right

A random passphrase — several random words chosen from a large word list — can be both memorable and high-entropy. The Diceware method uses a list of 7,776 words (six-sided dice roll five times) and produces about 13 bits per word. A five-word passphrase from Diceware is about 65 bits — comparable to a 10-character fully random password. A six-word passphrase is about 78 bits, and a seven-word passphrase is about 90 bits.

The requirement is that the words are genuinely random. Picking words yourself doesn't work; humans don't generate randomness. Use dice, or a password manager's built-in passphrase generator.

Password managers are the right answer

The best password strategy is: use a password manager, let it generate a unique random password for every account, and use one very strong master password (probably a Diceware passphrase) to unlock the manager. This gives you strong unique passwords everywhere with no memorization burden except for the master.

Common password managers in 2026 that I'd recommend: 1Password (commercial, well-designed), Bitwarden (open source with a paid tier, works everywhere), KeePassXC (fully local, no cloud dependency if you don't want one). Any of these is better than reusing passwords or trying to memorize dozens of unique ones.

What makes a bad password

Any word or phrase in a dictionary

Cracking dictionaries include not just English but every language, every technical vocabulary, every song lyric, every movie quote, every book title. If someone has written it down anywhere, it's in the dictionary.

Personal information

Names, birthdays, addresses, phone numbers, pet names, employer names — all guessable by someone who does even a little research. Even if you don't share this information publicly, data breaches make it available.

Reused across sites

Even a genuinely strong password becomes weak once you use it in multiple places. When one site gets breached and the password leaks, attackers try it against every other service you use. This attack ("credential stuffing") is behind a huge fraction of account compromises.

Slightly modified from a previous password

If your password was "Rainbow2023" and you change it to "Rainbow2024," you've barely improved anything. Password change policies that force minor variations produce this pattern reliably. Attackers assume it.

Composed of predictable patterns

Substituting @ for a, 3 for E, ! at the end, capitalizing the first letter — all patterns that dictionary attackers try first. "P@ssw0rd!" has essentially the same effective strength as "password" for cracking purposes.

Multi-factor authentication changes everything

Even a mediocre password is much safer with a second factor. TOTP-based two-factor (authenticator apps like Google Authenticator or Authy), hardware keys (YubiKey), or push-based approvals (Duo, Microsoft Authenticator) all defeat the vast majority of password-based attacks.

SMS-based two-factor is better than nothing but has real weaknesses — SIM swap attacks let sophisticated attackers redirect your SMS to their phone. For high-value accounts, hardware keys or authenticator apps are meaningfully more secure than SMS.

The practical advice: use MFA everywhere it's offered, prefer authenticator apps or hardware keys over SMS, and use unique strong passwords per account so that even if one gets cracked, the damage is contained.

Common questions

"How often should I change my password?"

Only when there's a reason to. Forced periodic password changes were considered good practice for years but are now understood to be counterproductive — they push users toward minor variations of previous passwords. NIST officially withdrew the recommendation to change passwords on a schedule. Change your password when a service is breached, when you suspect it might be compromised, or when you're worried about it. Otherwise, leave a strong unique password in place indefinitely.

"Are password strength meters accurate?"

Some are, some aren't. Most just count character classes and length, which produces misleading results for common patterns. The zxcvbn library (originally from Dropbox) attempts to evaluate against real cracking dictionaries and produces much more accurate estimates. This tool uses similar analysis.

"Is my password on a breach list?"

Have I Been Pwned maintains a database of leaked passwords from breaches. You can check whether a specific password has ever appeared in any known breach without sending the full password (they use a k-anonymity API that only sends a hash prefix). Any password that's ever appeared in a breach is functionally worthless — attackers have it in their dictionaries.

Related tools

If you're generating random values for identifiers, the UUID Generator produces cryptographically random UUIDs. The Hash Generator is what you use to hash things, but not what you should use to store passwords (raw hashing is too fast for password protection — use a purpose-built KDF).

Privacy

The entropy calculation runs entirely in your browser. Passwords you enter here are never sent anywhere. You can verify this by opening browser developer tools and watching the network tab — nothing transits when you type or click compute. That said, obviously don't paste your actual current password into any web form as a matter of principle; test with example values that resemble your patterns instead.