Password Combination Calculator

It depends entirely on length and the character pool. For a 12-character password drawn from 62 characters (letters and digits), there are 62¹² ≈ 3.23 × 10²¹ possible strings. For a 4-digit PIN there are 10⁴ = 10,000. The calculator above lets you set any combination of these parameters instantly.

Use N = C^L, where C is the number of distinct characters available and L is the password length. Count up your character types: lowercase (26) + uppercase (26) + digits (10) = 62. Then raise 62 to the power of your target length. That gives the theoretical count of all distinct strings of that length from that pool.

With digits only (C = 10): 10⁸ = 100,000,000. With lowercase letters only (C = 26): 26⁸ = 208,827,064,576. With letters and digits (C = 62): 62⁸ = 218,340,105,584,896. With all printable ASCII (C = 94): 94⁸ = 6,095,689,385,410,816. The choice of character set makes a very large difference.

With alphanumeric characters (C = 62): 62¹² ≈ 3.23 × 10²¹. With all printable ASCII (C = 94): 94¹² ≈ 4.76 × 10²³. These numbers exceed the estimated number of grains of sand on Earth (≈ 7.5 × 10¹⁸), which is why randomly generated passwords at this length are infeasible to brute-force under most attack models.

N = C^L, where N is the number of possible passwords, C is the character pool size, and L is the password length. Each of the L positions can independently hold any of the C characters, so there are C choices per position and C × C × … (L times) = C^L total strings. When repetition is not allowed, the formula becomes P(C,L) = C! / (C − L)!.

Password entropy is H = L × log₂(C), measured in bits. It is the base-2 logarithm of the number of possible passwords. A 12-character alphanumeric password has H = 12 × log₂(62) ≈ 12 × 5.954 ≈ 71.45 bits. This figure assumes uniform independent character selection. If the password is human-chosen rather than machine-generated, the effective entropy is lower because human choices follow predictable patterns.

Passwords are ordered strings, so "abc" and "cba" count as two different passwords. The relevant count is an ordered one: C^L with repetition allowed, or P(C,L) = C!/(C−L)! without repetition. The mathematical combination formula C(n,r) = n!/(r!(n−r)!) ignores order and does not apply to password counting. When people say "password combinations" they actually mean ordered strings — not combinations in the strict mathematical sense.

Yes, because you never enter a real password here. The calculator works from rules only — length and character types — and performs all arithmetic locally in your browser. Nothing is sent to a server. There is no input field for an actual password value, and the results depend only on the rules you select, not on any secret.

Without repetition the count is P(C,L) = C! / (C−L)!, which is always smaller than C^L. If L > C, no valid password exists and the count is zero — you cannot fill more positions than there are unique characters. For example, a 7-character password from a 62-character pool without repetition gives 62 × 61 × 60 × 59 × 58 × 57 × 56 ≈ 3.26 × 10¹². The Advanced tab in the calculator handles this mode.

Adding symbols expands the pool from 62 to 94 characters, which multiplies the combination count by roughly 1.5 per character position. That helps theoretically. For randomly generated passwords, adding one extra character of any type has a larger effect than switching to a bigger pool, because each extra position multiplies the search space by the full pool size. For human-chosen passwords, predictable substitutions like @ for a or 3 for e offer little real protection against dictionary attacks that already include these patterns.

Average exhaustive-search time: T_avg = N / (2R), where R is the guess rate in attempts per second. Worst case: T_worst = N / R. For example, 3.23 × 10²¹ candidates at 10⁹ guesses per second gives T_avg ≈ 1.6 × 10¹² seconds ≈ 51,000 years. These figures apply only to uniform exhaustive search. Real attacks against predictable or reused passwords are far faster.

The search space is the set of all candidate strings an attacker would need to consider under a given attack model. It is determined by the assumed length range, character pool, and any known constraints. For an attacker who knows only that a password is exactly 12 characters from a 62-character pool, the search space is 62¹² ≈ 3.23 × 10²¹. If the attacker also knows the password is a dictionary word with a number appended, the effective search space is far smaller.

When passwords can vary in length from L_min to L_max, the total count is the sum: C^L_min + C^L_min+1 + … + C^L_max. Because each term is C times larger than the previous one, the longest-length term dominates almost entirely. For a 62-character pool from length 8 to 12, the total is ≈ 3.28 × 10²¹ — only about 1.6% larger than 62¹² alone. The Advanced tab calculates this correctly using the full summation.

A standard 4-digit PIN uses digits 0–9 (C = 10) with repetition allowed, giving 10⁴ = 10,000 possible combinations. If PINs cannot start with 0 the count drops to 9 × 10³ = 9,000. A 6-digit PIN gives 10⁶ = 1,000,000 combinations. These counts assume each digit is chosen independently — real users disproportionately choose PINs like 1234, 0000, and birth years, so practical guessing difficulty is much lower than 10,000 implies.