Password Generator

Entropy counts the search space an attacker has to try before guessing correctly, expressed in bits. Each bit doubles the number of possible passwords, so entropy grows exponentially with length and only logarithmically with the size of the character set. A password built from lowercase letters, uppercase letters, digits, and symbols draws from a set of 88 characters in this generator, which works out to about 6.46 bits per character (log2 of 88). A 16-character password from that full set sits around 103 bits of entropy; the same length using only lowercase letters drops to about 75 bits, because each character only contributes log2(26), roughly 4.7 bits.

This is why length dominates complexity in practice. Adding four more characters to a lowercase-only password (75 bits at 16 characters, about 94 bits at 20) closes more of the gap with a shorter mixed-character password than swapping a handful of letters for symbols does. Complexity rules that force one uppercase letter and one digit into an otherwise short password add very little entropy, because they constrain where those characters can appear rather than expanding the overall search space.

None of this is a precise cracking-time estimate - actual guessing speed depends on the hashing algorithm protecting the password on the server, which this generator cannot know. Entropy measures the password itself, independent of how it gets attacked later.

• Length contributes linearly to the exponent - every extra character multiplies the search space by the alphabet size
• Character-set size contributes logarithmically - doubling the alphabet only adds one bit per character
• A long password from a small alphabet often beats a short password from a large one
• Entropy assumes uniform random selection; a password chosen by a human mind (even one that feels random) is not equivalent to one drawn from a cryptographically secure generator

The generator shows the password itself, a strength meter from 0 to 100, and the time it took to generate - all recalculated the moment any option changes. The strength score is not raw entropy in bits; it is a composite heuristic that rewards length thresholds (12 and 16 characters both add points), rewards using multiple character types, rewards character variety within the password, and penalizes patterns like repeated-character runs or a password drawn from only one character class.

The five-band label under the meter is only meaningful for comparing outputs from this tool against each other. A password scored in the top band here is not automatically safe for every context - a service with weak hashing or a short mandatory length cap can undermine it regardless of what any client-side meter reports.

Turning on "exclude ambiguous characters" removes the characters most often confused in print or handwriting (0, O, o, l, I, 1) after the rest of the options have been applied. This slightly shrinks the character set and therefore slightly lowers entropy at a fixed length, which is a deliberate readability trade-off rather than a security setting.

The length slider runs from 8 to 64 characters. Eight characters was a reasonable minimum when set as a common policy floor years ago; against modern offline cracking hardware it is thin even with a full character set, since the search space is a fixed number regardless of how the site later hashes it. Most current guidance, including NIST SP 800-63B, has moved away from mandating character-composition rules and toward rewarding length directly - a minimum of 8 characters but up to 64 allowed, with a preference for longer passphrases over short complex strings.

The minimum-numbers and minimum-symbols sliders (0 to 10 each) force a certain count of that character type into the result, then shuffle it into a random position. This is a compatibility setting more than a security one: some legacy account forms still reject a password made purely of letters, or specifically demand a digit and a symbol, and this guarantees the output passes that check on the first try.

Setting a large minimum for both numbers and symbols on a short overall length reduces the pool of positions left for the general character set, which can make the arrangement slightly more predictable than a password where every position is drawn freely from the full alphabet. This effect only matters at the margins - at 16 characters or longer with modest minimums (0-2), the difference is negligible.

A passphrase built from several random dictionary words works on the same entropy math, with a different alphabet: instead of characters, each unit is a word drawn from a wordlist. A four-word passphrase from a 7,776-word list (the size used by the well-known EFF and Diceware wordlists) carries about 12.9 bits per word, so four words reach roughly 51.7 bits and five reach about 64.6 bits - comparable to or better than an 8-12 character random password, while being considerably easier to type and remember.

The trade-off is length in characters: a five-word passphrase is typically 25-40 characters including separators, longer to type but composed of memorable units rather than arbitrary symbols. Passphrases only reach their claimed entropy if the words are selected uniformly at random from a fixed list - choosing "memorable" words by hand collapses the actual search space far below the theoretical figure.

This generator produces character-based passwords rather than word-based passphrases. For an account where typing accuracy matters more than raw entropy per character (a device PIN pad, a shared terminal, a password read aloud over the phone), a passphrase-style generator built for that approach is a better fit than pushing the length slider here to compensate.