SSOGEN / Free tools / Password Entropy Calculator: Bits, Guess Time and the NIST Rules
Free tool
Password Entropy Calculator: Bits, Guess Time and the NIST Rules
This password entropy calculator gives the bits for a typed or randomly generated password, flags common passwords and keyboard patterns, and shows how long guessing would take. It runs in your browser and sends nothing.
Check a password
Select “A password I typed or chose” to test one, or “I generated it randomly” to enter the character set and length of a random string. Nothing runs until you press Check.
Use a similar password, not your real one. It is read only in this page and never sent anywhere.
Only valid if every character was picked independently and evenly at random by a program, not by a person.
Private by design. This page makes no network request when you check, stores nothing and logs nothing. Even so, do not type a real password into any web page you do not trust. Test a similar one: same length, same style of characters.
Press Check to see the entropy, the common-password check, guess times and the NIST comparison.
Free, in your browser. There is no sign-up and no limit. The page makes no network request when you check, keeps nothing in storage and writes nothing to a log.
Even so, do not type a real password into any web page you do not trust, including this one if you have not read its source.
Test a similar password instead: the same length and the same style of characters give the same answer.
What password entropy measures
Password entropy measures how many guesses a password would take, expressed in bits. A password with 40 bits has 2^40 equally likely possibilities.
- Random password. The number is exact only when the password was chosen at random.
- Human-chosen password. The usual length-and-character-types formula gives an upper bound, and the real figure is lower.
- This calculator. It shows both cases, labeled, and adds the checks the formula leaves out.
What does entropy in bits mean?
Each bit doubles the number of possibilities. A password drawn at random from N equally likely options has log2(N) bits, so 10 digits give 3.32 bits per digit and a six-digit PIN has about 19.9 bits.
An attacker who tries them one by one finds the answer, on average, after searching half the space, which is why the guess times above use 2^(bits - 1).
For a typed password the tool uses length x log2(pool), where the pool is the number of different characters the password could have drawn on:
- Lowercase letters: 26.
- Plus uppercase: 52.
- Plus digits: 62.
- Plus the 32 ASCII punctuation marks and the space: 95.
Characters outside ASCII get an assumed pool of 100 here. That value is a judgment call, not a standard.
Why composition-based estimates mislead
The formula assumes every character was chosen independently and uniformly. People do not type that way.
A person who must include a capital, a digit and a symbol writes “Summer2026!”. The pool formula credits it with 11 characters from a pool of 95, about 72 bits.
A guessing tool that tries dictionary words, then a capital first letter, then a year, then a trailing symbol reaches it within a tiny share of that space.
NIST’s current rules (SP 800-63B-4, section 3.1.1.2, read 2026-10-09) reflect this. Services must not impose “one capital, one symbol” rules, and they must check new passwords against a blocklist of common and leaked ones.
The reason for both is that people are predictable: length and a blocklist check beat complexity rules.
The same section sets the numbers this tool checks against:
- 15 characters minimum if the password is the only factor.
- 8 if it is one part of multi-factor sign-in.
- 64 is the longest password a service should accept.
The tool therefore does three things the formula does not.
- Common passwords. It checks your typed password against a built-in list of 100 well-known weak passwords, including the usual disguises (a capital first letter, digits or symbols on the end, 0 for o, @ for a).
- Patterns. It looks for keyboard walks like “qwerty” or “asdf”, counting runs like “1234” or “dcba”, one character repeated four or more times, and a block repeated across the whole password.
- Upper bound. It labels the bit count as an upper bound whenever any of these appear.
It does not substitute an invented lower figure, because without a real guessing model no defensible number exists.
Random versus human-chosen
The tool’s second mode gives an exact answer on one condition: a program picked each character independently and uniformly.
Entropy is then length x log2(set size), regardless of how the result looks. “x7#kQ9vLm2pR” and “aaaaaaaaaaaa” are equally likely generator outputs, though only one looks random.
The condition fails as soon as a person edits the output. Each of these shrinks the space, usually by an amount you cannot measure:
- Regenerating. Trying again until you like the result.
- Swapping. Replacing a character you dislike.
- Dropping symbols. Removing the symbols a site refuses.
If you chose any part yourself, use typed mode and treat the result as an upper bound.
Generating well matters more than the arithmetic.
For a random password, token or key, use a generator that draws from the browser’s or the operating system’s secure random source.
Our random string generator and API key generator do that. Do not build your own on a date-seeded random function.
Passphrase math
A passphrase of words picked at random from a list is easy to remember, and its entropy can be counted exactly.
- Dice. Each word of the EFF’s long list is chosen by rolling five dice.
- Per word. That gives 6^5 = 7,776 words and log2(7,776) = 12.92 bits per word.
- Six words. The EFF’s page on dice-generated passphrases (read 2026-10-09) puts a six-word passphrase at one of 221,073,919,720,733,357,899,776 alternatives, about 2^77, which matches 7,776^6.
The same condition applies: dice or a program must choose the words, not you.
Four words you thought up yourself, or a line from a song, do not carry 51.7 bits. They carry whatever an attacker’s phrase list says they do.
Bits for common choices
All rows assume random selection. The last column is the average time at 10^10 guesses per second against a fast hash, one of the three illustrative speeds the calculator uses.
The times are formula output on that assumption, not a measurement.
| Choice | Bits | Average time, offline fast hash |
|---|---|---|
| 6 random digits | 19.9 | less than a second |
| 8 random lowercase letters | 37.6 | 10.4 seconds |
| 8 random letters and digits | 47.6 | 3 hours |
| 8 random printable ASCII | 52.4 | 3.5 days |
| 4 random dice words | 51.7 | 2.1 days |
| 12 random lowercase letters | 56.4 | 55.2 days |
| 5 random dice words | 64.6 | 45 years |
| 15 random lowercase letters | 70.5 | 2.7 thousand years |
| 12 random letters and digits | 71.5 | 5.1 thousand years |
| 6 random dice words | 77.5 | 350 thousand years |
| 12 random printable ASCII | 78.7 | 754 thousand years |
| 7 random dice words | 90.5 | 2.7 billion years |
| 16 random letters and digits | 95.3 | 75.5 billion years |
The table is mainly about length. Going from 8 printable-ASCII characters to 12 adds 26 bits, which is worth more than any symbol rule.
Fifteen random lowercase letters beat eight random characters of every kind.
Attacker speeds are assumptions
The calculator shows three speeds, each a stand-in:
- Online, throttled is 100 guesses a second. NIST’s rate-limiting rule for services caps consecutive failed attempts at 100, and a real service usually allows far fewer in a given time.
- Offline, slow hash is 10,000 guesses a second, for a stolen password database where each password was stored with a deliberately slow hash.
- Offline, fast hash is 10 billion guesses a second, for a stolen database hashed with a fast general-purpose function and an attacker with serious hardware.
Real speeds vary by orders of magnitude with the hash, its settings and the hardware.
To adjust, scale: ten times the speed means one tenth of the time, or about 3.3 bits.
The gap between the speeds is the point. The same password can hold for centuries against a throttled login and fall in days against a stolen fast-hashed database.
The length you need therefore depends on how the service stores passwords, which you usually cannot see.
What to do with the result
- If the check flagged a common password or a pattern: change it everywhere you use it, whatever the bit count says.
- If it is a typed password under 15 characters: make it longer. Length is the main lever in the NIST rules.
- Use a password manager to generate and store a unique random password for each account. Reuse is what turns one breach into many; see credential stuffing and password manager versus SSO.
- Keep a short passphrase for the few secrets you must remember, such as the manager’s master password, and build it from dice-chosen words.
- Turn on multi-factor authentication or move to passwordless sign-in where a service offers it, so that a guessed or leaked password is not enough on its own.
- If you set policy for others, read what NIST SP 800-63B-4 requires and what each password policy setting does.
How much entropy should a password have?
How do you calculate password entropy?
How secure is my password?
Is it safe to type my password into this page?
Why does a longer password beat a complex one?
How many bits is a six-word passphrase?
Where to go next
- Free tools. Browse the other free tools.
- Password rules. Read how NIST SP 800-63B-4 and a password policy set length, blocklists and expiry.
Sources, all read 2026-10-09: NIST SP 800-63B-4, section 3.1.1.2 for the length, composition, blocklist and maximum-length rules; the EFF’s page on dice-generated passphrases for the dice list and the six-word figure.