The password combination calculator above answers a policy question: given a required length and an allowed character set, how many distinct passwords exist, how many bits of entropy is that, and how long would an attacker need to try them all at a given rate? It computes the exact count using arbitrary-precision arithmetic rather than approximating it, and it runs entirely in your browser.
Arb Digital publishes this alongside its other free developer and security tools because the size of a keyspace is the number that should drive a password policy, and it is almost never the number people quote. Committee discussions revolve around whether to demand a symbol; the arithmetic says that adding two characters of length usually beats it comfortably.
What This Calculator Does, and How It Differs From Entropy Scoring
This page measures a policy. You give it a length and a pool size, and it reports the number of possible passwords, the equivalent bits, and a search time. Nothing secret is entered, because nothing secret is needed.
The neighbouring password entropy calculator measures a specific password. You type a value, it inspects which character classes appear, and it reports bits and crack time for that string along with warnings about patterns that make the figure optimistic. Use that one when you have a password in hand; use this one when you are writing a rule, comparing two policies, or sizing a token or licence key format.
Both answer with bits, and both use the same underlying relationship, but the questions differ. “How large is the space this rule creates” is a design question. “How strong is this particular string” is an assessment question, and it comes with a caveat this page does not need: a human-chosen password never fills its nominal keyspace.
How to Use It
- Set the length your policy requires. If you are modelling a passphrase, the length is the number of words, not the number of letters.
- Choose the character set. Or enter a custom pool size, which is how you model a word list, a restricted alphabet, or a licence key format.
- Pick an attacker rate that matches your storage. A slow, salted hash and a raw MD5 differ by around seven orders of magnitude.
- Read the bits figure, not just the combination count. Bits compare cleanly across policies; a number with nineteen digits does not.
- Look at the table of nearby lengths. It shows the cost of one more character, which is the decision most policies actually face.
The Formula and How It's Calculated
For a fixed length, every position is chosen independently from the pool, so the count is a simple power:
combinations = poollength and entropy in bits = length × log₂(pool)
Take an eight-character password from the 62-character alphanumeric set. That is 628 = 218,340,105,584,896 possibilities, a little over 218 trillion. In bits, log₂(62) is 5.954 bits per character, so eight characters carry 47.63 bits. An attacker must search half the space on average, so 109,170,052,792,448 guesses. At 100 billion guesses per second against a fast unsalted hash, that is about 1,092 seconds — roughly eighteen minutes. The same password against bcrypt at 20,000 guesses per second would take about 173 years.
If the rule permits any length up to the maximum, the total is the sum of a geometric series, pool1 + pool2 + … + poolL. For a pool of 62 that sum is only about 1.6 per cent larger than the final term alone, because each length is 62 times bigger than the one before it. Every shorter length combined is a rounding error against the longest one, which is why maximum length is the only part of a length rule that matters.
The tool computes the powers exactly using arbitrary-precision integers, then converts to bits with logarithms. That distinction is worth noting: a floating-point calculation of 9564 loses its low-order digits entirely, so the exact digit count shown here comes from integer arithmetic rather than from an approximation.
Why This Number Is a Ceiling, Not a Prediction
The keyspace is the size of the space a policy permits. It is what an attacker faces only if the password was drawn uniformly at random from that space. A password generator satisfies that condition; a person does not.
Real attacks do not enumerate. They start from leaked password lists, dictionaries, keyboard walks, dates, names and the substitution rules everyone applies. A twelve-character password that is a dictionary word plus a year plus an exclamation mark occupies a keyspace of 6212 on paper and is generated within the first few million candidates in practice. The gap between the two figures is not small; it is many orders of magnitude.
This is why NIST Special Publication 800-63B, Digital Identity Guidelines requires verifiers to check candidate passwords against lists of commonly used, expected and compromised values, and states that verifiers should not impose composition rules requiring mixtures of character types, nor require passwords to be changed arbitrarily or periodically. A blocklist attacks the gap between the nominal keyspace and the real one; a symbol requirement does not.
Where the Keyspace Figure Is Exactly Right
There is a case where this arithmetic is not a ceiling but a measurement: values generated at random by a machine. API keys, session tokens, licence keys, reset links, one-time codes and generated passwords all come from a known alphabet with a known length, and if the generator is cryptographically secure then every value in the space is equally likely. The count on this page is then the exact number an attacker must search.
Two design rules follow. First, use a cryptographically secure random source, not a general-purpose one. RFC 4086, Randomness Requirements for Security, is the standard reference on this, and its central warning is that statistical randomness and cryptographic unpredictability are different properties — output that passes randomness tests can still be reproducible if the process behind it was predictable. Second, size the token so that guessing is hopeless even at an unrealistic rate: 128 bits, which is 22 characters from a 62-character alphabet or 32 hexadecimal digits, is the usual target. For values you need to generate, the password generator and UUID generator cover the common cases.
Passphrases and Why the Pool Can Be a Word List
The same formula works when the “characters” are words. A passphrase of five words chosen at random from a 7,776-word list has 7,7765 possibilities, which is about 28.4 quadrillion, or 64.6 bits. Set the length to 5 and the custom pool to 7,776 to see it. That beats an eight-character random alphanumeric password by seventeen bits while being far easier to remember and to type.
The condition is that the words must be selected at random, not composed into a sentence you thought of. A remembered phrase carries the entropy of the phrase choice, which is far lower than the word count suggests, because natural language is highly predictable and grammatical structure eliminates most combinations. Rolling dice or using a generator preserves the arithmetic; writing something memorable does not. If you want to compare the information content of arbitrary strings rather than uniform selections, the Shannon entropy calculator measures that directly, and the permutation calculator handles the related case where characters cannot repeat.
Arb Digital builds fast, hardened websites — modern password hashing, rate-limited logins, and tokens sized so guessing them is not a threat model.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Treating the keyspace as the difficulty of guessing a human-chosen password. It is the size of the space the rule permits, and people occupy a tiny, predictable corner of it.
- Requiring symbols instead of length. Moving from 62 to 95 characters adds about 0.6 bits per position; adding two characters at 62 adds about 11.9 bits in total.
- Imposing a maximum length. Capping a password at sixteen characters caps the keyspace, and it usually indicates the value is being stored in a way that should worry you.
- Quoting a crack time without the storage method. The same policy is centuries against bcrypt and minutes against an unsalted fast hash.
- Believing a large keyspace makes a reused password safe. A breach anywhere exposes it everywhere, and no amount of length repairs that.
Related Free Tools From Arb Digital
To score a password you already have, use the password entropy calculator, and to create one use the password generator. The Shannon entropy calculator measures the information content of arbitrary text, the permutation calculator and factorial calculator handle related counting problems, and the UUID generator produces unique identifiers. If you are auditing how existing passwords were stored, the hash type identifier recognises the format. Everything else is in the free online tools hub.
Frequently Asked Questions
With the 62-character alphanumeric set it is 62 to the power 8, which is 218,340,105,584,896 — about 218 trillion, or 47.63 bits. With all 95 printable ASCII characters it rises to about 6.6 quadrillion, or 52.6 bits.
This tool measures a policy: a length and a character set, giving the size of the space they permit. An entropy calculator measures one specific password you type in, reporting the bits and crack time for that string.
Length, in almost every case. Moving from 62 to 95 permitted characters adds roughly 0.6 bits per position, while two extra characters at a 62-character pool add about 11.9 bits, and length does not make a password harder to remember in the same way.
Barely. The total for all lengths up to the maximum is a geometric sum dominated by the longest term. With a 62-character pool, every shorter length combined adds about 1.6 per cent to the total.
Aim for at least 128 bits, which is 22 characters from a 62-character alphabet or 32 hexadecimal digits. At that size, exhaustive search is not a threat under any realistic guess rate.
Set the length to the number of words and the pool to the size of the word list. Five words from a 7,776-word list gives about 64.6 bits, provided the words were chosen at random rather than composed into a phrase.
Because guess rates depend on how the password was stored. 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.
No, and you should not. This tool needs only a length and a pool size. It runs entirely in your browser, makes no network request, and stores nothing.
This calculator sizes a keyspace from a length and a character set for educational and planning purposes. It does not assess any individual password, does not check breach databases, and a large keyspace is not by itself evidence that a system is secure.
