The password entropy calculator above measures how large a search space a password occupies, expressed in bits, and converts that into a crack time under an attacker model you choose. It does this entirely inside your browser. There is no form submission, no analytics call, no fetch, and no storage of any kind on this page — the characters you type never leave the machine you typed them on, which is the only acceptable design for a tool of this sort.
Arb Digital publishes this alongside its other free security and developer utilities because entropy is the number that actually governs password strength, and almost every strength meter people encounter reports something else: a score out of four, a colour, or a checklist of composition rules. Bits are comparable across passwords, across schemes, and against published guidance. A colour is not.
What This Password Entropy Calculator Does
Entropy in this context is a measure of unpredictability, and for a password drawn uniformly at random from a known alphabet it is straightforward: the number of bits is the length multiplied by the base-two logarithm of the alphabet size. The calculator inspects which character classes your password actually uses, sums the pool accordingly, and reports the result. It shows the pool size and the length separately so you can see which of the two is doing the work.
It also converts bits into an expected crack time. That conversion needs an assumption about how fast an attacker can test guesses, and the dropdown makes that assumption explicit rather than burying it, because the spread is enormous. The same password can be uncrackable against a rate-limited login form and trivial against an offline attack on a leaked database of unsalted hashes. The password did not change; the storage did.
Boundary worth stating: this tool scores a password you already have. If you need to create one, our password generator builds random strings, and because it generates from a known alphabet, its output is one of the few cases where the entropy figure here is exactly correct rather than an upper bound.
How to Use It
- Type or paste a password. The field is masked by default; tick the show box to read it back. Either way the value stays on your device.
- Read the bits figure first. It is the only number that compares meaningfully between two different passwords.
- Choose an attacker model that matches your threat. A password protecting a well-built web login faces a very different rate from one protecting an encrypted archive.
- Check the character-class line. It shows exactly which classes contributed to the pool, which explains the pool size rather than leaving you to guess.
- Read the warning line. It flags the patterns that make a naive entropy figure an overstatement.
The Formula and How It's Calculated
The calculation is:
Entropy in bits = length × log₂(pool size)
Pool size is the sum of the classes present: 26 for lowercase letters, 26 for uppercase, 10 for digits, 33 for the printable ASCII symbols including space, and an allowance for characters outside ASCII. So a password using lowercase, uppercase and digits draws from 26 + 26 + 10 = 62 characters, and log₂(62) is 5.954 bits per character. A twelve-character password of that kind carries 12 × 5.954 = 71.4 bits. Switching the pool assumption to the full printable ASCII set of 95 raises the per-character figure to 6.570 bits, which is why composition rules feel more productive than they are: adding one symbol to a twelve-character password gains you about seven bits, while adding two more characters gains you about thirteen.
Crack time assumes an attacker must search on average half the space, so expected guesses are 2bits ÷ 2, and the time is that divided by the guess rate. RFC 4086, the IETF Best Current Practice document on Randomness Requirements for Security, works through this style of calculation for passwords and keys and is worth reading for its central warning: statistical randomness and cryptographic unpredictability are not the same thing, and a password that looks random can still be cheap to reproduce if the process that generated it was predictable.
Why This Number Is an Upper Bound, Not a Measurement
The formula above is exactly right for one case: a password chosen uniformly at random from the stated alphabet. For a password a human invented, it is an optimistic ceiling, sometimes by a very large margin. The reason is that real attacks do not enumerate the search space in order. They start with leaked password lists, dictionaries, keyboard patterns, dates, names, and the substitution rules everybody uses.
The default in the box above illustrates it. Eleven characters spanning all four classes scores around 72 bits, which sounds strong. But it is a dictionary word with three predictable substitutions and a digit appended, and a rule-based cracker generates exactly that shape early in its run. Its real-world strength is a small fraction of the calculated figure. Meanwhile a passphrase of four random common words carries no symbols and no digits, scores lower on any composition checklist, and is genuinely harder to guess because the randomness is real. This is the single most important thing to understand about entropy figures: they measure the space you could have drawn from, not the process you actually used.
What the Current Guidance Actually Says
Password advice changed substantially and many organisations have not caught up. NIST Special Publication 800-63B, Digital Identity Guidelines, sets a minimum of 8 characters for user-chosen secrets and requires verifiers to check candidate passwords against lists of commonly used, expected and compromised values. Notably, it states that verifiers should not impose composition rules such as requiring mixtures of character types, and should not require passwords to be changed arbitrarily or periodically — a forced change is required only when there is evidence of compromise.
The logic follows directly from the previous section. Composition rules push people toward predictable transformations of words they already know, which raises the calculated entropy while lowering the real entropy. Periodic rotation pushes them toward incremental variants, which an attacker who has one old password can guess immediately. Length, a blocklist check against breached passwords, and support for password managers do more than any complexity rule. The same document explicitly encourages allowing paste so that managers work properly.
Why the Storage Method Dominates the Answer
Change nothing about a password and vary only how the service stored it, and the crack time moves by ten orders of magnitude. A modern password hash such as bcrypt, scrypt or Argon2 is deliberately slow and memory-hard, so a well-equipped attacker manages tens of thousands of guesses per second. An unsalted general-purpose hash such as raw MD5 or SHA-1 is designed to be fast, and commodity GPU rigs test them in the tens of billions per second. That is the difference between a 60-bit password surviving for centuries and falling in days.
Two consequences follow for anyone building systems rather than choosing passwords. Salting matters independently of speed: without a unique salt per user, one precomputed table breaks every account at once, and identical passwords are visible as identical hashes. And rate limiting on the login path is the cheapest control available, because it caps the online attack rate regardless of everything else. If you are working with hashes directly, our hash generator produces them for testing, though it should never be used to hash a real password for storage.
Reading the Bands Sensibly
Rough conventions are useful as long as you remember they assume genuine randomness. Below about 40 bits is weak against any offline attack. Around 60 bits is reasonable for a low-value account behind rate limiting. Around 80 bits is a sensible target for anything that matters. Above 100 bits, the password stops being the weakest part of the system by a wide margin, and effort is better spent on multi-factor authentication and on where the password is stored.
That last point deserves emphasis, because entropy arithmetic tempts people into optimising the wrong thing. A 128-bit password reused across three services is weaker in practice than a 60-bit password used once, since a breach anywhere exposes it everywhere. Uniqueness per site and a second factor both beat additional length once you are past the low bands. For the generated identifiers and tokens that sit alongside passwords in most systems, the UUID generator and the random number generator cover the cases where you need unpredictable values rather than memorable ones.
Arb Digital builds fast, hardened websites — proper password hashing, rate limiting, and no credentials sitting in plain text anywhere.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Treating the bits figure as a measurement of a human-chosen password. It is a ceiling that assumes uniform random selection, and dictionary-based attacks never search uniformly.
- Chasing character classes instead of length. Two more characters usually buys more entropy than one more symbol, and does it without making the password unmemorable.
- Substituting digits for letters and calling it strong. Rule-based crackers apply those substitutions automatically and early.
- Quoting a crack time without stating the attacker model. The same password ranges from centuries to minutes depending purely on how it was stored.
- Reusing a high-entropy password across services. One breach exposes every account, and no amount of length repairs that.
Related Free Tools From Arb Digital
To create a password rather than score one, use the password generator. The random number generator produces unpredictable values in a numeric range, and the UUID generator handles unique identifiers. For working with digests during development there is the hash generator, which should never be used to hash a live password for storage. The character counter is handy for checking length limits. Everything else is in the free online tools hub.
Frequently Asked Questions
No. The calculation runs entirely in your browser using local JavaScript. This page makes no network request of any kind, stores nothing, and logs nothing, so the characters you type are never transmitted or seen by us or anybody else.
Entropy in bits equals the password length multiplied by the base-two logarithm of the character pool size. A twelve-character password using lowercase, uppercase and digits draws from a pool of 62, which is 5.954 bits per character, giving about 71.4 bits in total.
It depends on the threat. Around 60 bits is reasonable for a low-value account behind rate limiting, and around 80 bits is a sensible target for anything that matters. Above roughly 100 bits the password stops being the weakest part of the system.
Because the formula assumes the password was chosen uniformly at random. A dictionary word with predictable substitutions and a digit appended occupies the same nominal space but is generated early by rule-based cracking software, so its real strength is far lower than the calculated figure.
Usually not. Adding one symbol to a twelve-character password gains about seven bits, while adding two more characters gains about thirteen. Length is also easier to remember, which is why current guidance favours it over composition rules.
No. NIST Special Publication 800-63B states that verifiers should not require memorized secrets to be changed arbitrarily or periodically, and should force a change only when there is evidence of compromise. It also advises against imposing character-composition rules.
Because guess rates differ by many orders of magnitude depending on storage. A slow, salted hash such as bcrypt limits an attacker to tens of thousands of attempts per second, while an unsalted fast hash allows tens of billions on commodity hardware.
Often yes, provided the words are chosen at random rather than written as a phrase you thought of. Randomly selected words give real, countable entropy and are far easier to remember, whereas a memorable sentence carries much less unpredictability than its length suggests.
This calculator is an educational tool that estimates an upper bound on password strength from length and character pool. It does not audit your accounts, check any breach database, or constitute a security assessment, and a high entropy figure is not a guarantee that a password is safe to use. Nothing entered on this page is transmitted or stored.
