Password Generator: Entropy, Length, and What Cracks First

Password cracking is not blind guessing. Tools like hashcat work through wordlists of real leaked passwords — hundreds of millions of them from past breaches — and apply mangling rules that mimic exactly what people do: capitalize the first letter, append a year, swap a for the at sign, add an exclamation point at the end. A password like Summer2026 sits within the first few seconds of a competent cracking run, and its dressed-up cousin S u m m e r with substitutions lasts barely longer, because those substitutions are themselves in the rulebook.

Keyboard walks like qwerty123 and 1qaz2wsx, pet names plus birth years, sports teams, and song lyrics are all catalogued patterns. The uncomfortable truth is that anything memorable enough for a human to invent is structured, and structure is what wordlist-plus-rules attacks exploit. Attackers do not search the full space of possible strings; they search the tiny corner humans actually live in.

The other human failure is reuse. Credential stuffing — replaying an email and password pair leaked from one site against hundreds of others — succeeds without any cracking at all. A generator solves both problems at once: every password is patternless, and because you are not memorizing them, every account can have its own.

Not all randomness is equal. The ordinary random function in most programming languages, including Math.random in JavaScript, is a pseudorandom generator seeded from something guessable like a timestamp — fine for shuffling a playlist, disastrous for passwords, because an attacker who recovers the seed can replay the entire sequence. Password generation requires a cryptographically secure source, which in a browser means the crypto.getRandomValues API.

That API hands the request down to the operating system's entropy pool, which is continuously stirred with physical unpredictability: nanosecond-level timing jitter of interrupts, drive and network event timing, and on modern CPUs a dedicated hardware random instruction. The output is computationally indistinguishable from true randomness, meaning there is no seed to steal and no pattern to extrapolate.

One subtle implementation detail separates careful generators from naive ones: mapping random bytes onto a character set. A byte has 256 values; a character set of 62 does not divide 256 evenly, so taking the byte modulo 62 makes the first 8 characters of the set slightly more likely. A correct generator discards out-of-range bytes and draws again — rejection sampling — so every character is exactly equally likely. Because all of this runs client-side in your browser, the password exists only on your machine; nothing is transmitted, logged, or stored anywhere.

Entropy measures how many guesses an attacker needs, expressed in bits, where each additional bit doubles the search space. For a truly random password the formula is length times log base 2 of the character set size. Lowercase letters give 4.7 bits per character, letters plus digits give 5.95, and the full printable set with symbols gives about 6.55.

Run the numbers and the pecking order becomes obvious. An 8-character all-set password is about 52 bits — well within reach of an offline cracking rig working through a leaked database of fast hashes, where modern GPU clusters try billions of guesses per second. At 12 characters you reach about 79 bits, already impractical. At 16 characters you pass 104 bits, which is beyond any plausible brute force regardless of hardware growth, and at 20 characters the question stops being interesting.

The threat model matters as much as the number. Online guessing against a live login form is throttled to a handful of attempts, so even a modest password survives; the scenario that kills weak passwords is offline cracking after a site's hash database leaks, which happens routinely and without your knowledge. Since you cannot control how well a site hashes its passwords, the safe assumption is that any password may someday face an offline attack — which is exactly what 16-plus random characters are for.

Notice what the formula rewards: length multiplies entropy, while adding a character class only nudges the per-character rate. Going from 12 to 16 characters buys about 26 bits; adding symbols to a letters-and-digits password of the same length buys about 7. When a site's rules force a tradeoff, take length.

A passphrase is a sequence of random words — the diceware method draws from a list of 7,776 words, giving 12.9 bits per word, so six words is about 78 bits and seven words about 90. The critical requirement is that the words be chosen randomly, by dice or a generator; a sentence you invent has the same human-structure problem as any invented password and far less entropy than its length suggests.

The formats trade against each other on typing, not strength. A 16-character random string and a six-word passphrase are comparably strong, but the passphrase is dramatically easier to type on a phone keyboard, read aloud to a houseguest, or key into a TV interface, while the random string is shorter to store and immune to wordlist-aware attacks scaling with dictionary size. Neither format needs to be memorable if a password manager is doing the remembering.

The practical split: use a passphrase for the handful of secrets a human must produce from memory or speech — the password manager's master password, full-disk encryption, the Wi-Fi network — and use maximum-length random strings for everything the manager autofills. That is typically one to three passphrases in your head and hundreds of random strings in the vault.

Concrete defaults for the common cases, tuned to how each credential is actually used and attacked.