Password Generator

Entropy, in bits, measures how many guesses an attacker with no other information needs to try, on average, before finding your exact password by brute force. The formula is length × log2(pool size): if a password is built from a pool of 62 possible characters (lowercase, uppercase, digits) and is 12 characters long, that's 12 × log2(62) ≈ 71 bits — meaning an attacker would need to try, on average, half of 2^71 possible combinations before landing on the right one.

Every bit added to a password's entropy doubles the number of guesses an attacker needs, so entropy grows far faster from adding length than from adding more character types to an already-fixed length. Going from a 12-character password using only lowercase letters (pool of 26) to one that also includes digits and symbols (pool of roughly 94) raises entropy from about 56 bits to about 79 bits — but simply adding 4 more lowercase characters to reach 16 characters raises it to about 75 bits, almost the same gain, with none of the complexity rules to remember.

For years, the standard advice was to force complexity — at least one uppercase letter, one digit, one symbol — and to force periodic password changes every 60 or 90 days. Modern guidance, including NIST's Digital Identity Guidelines (SP 800-63B), has moved away from both of those specific rules: forced complexity tends to make people pick predictable patterns (Password1! is compliant with almost every complexity rule and is one of the first guesses in any real cracking attempt), and forced rotation tends to make people pick slightly incremented variants of their previous password, which is barely more secure and much harder to remember.

What current guidance emphasizes instead is length as the dominant factor, checking new passwords against lists of passwords already known to be in public breach databases (since a technically "complex" password is worthless if it's also one of the ten million most common ones), and not forcing rotation on a schedule — only when there's an actual reason to believe a password was compromised.

A passphrase built from several random dictionary words works on the same entropy math, just per-word instead of per-character: each word contributes log2(word list size) bits. Four words chosen randomly from a list of roughly 7,000 common words contribute about 4 × log2(7000) ≈ 51 bits — and because each additional word is easy to remember and type, it's realistic to add a fifth or sixth word for meaningfully more entropy in a way that's much harder to do by adding more random-looking characters to a traditional password.

The critical word there is randomly. A passphrase's security depends entirely on the words being selected independently and unpredictably from a reasonably large list — a phrase you'd actually say in conversation, or four words pulled from a sentence you like, is guessable through pattern-based attacks in a way that four genuinely independent random words are not. That's the whole reason a generator uses a cryptographically secure random source to pick each word, rather than letting a human "randomly" choose words themselves — humans are measurably bad at generating true randomness.

In practice, very few real account compromises happen through pure brute-force guessing against a single, well-implemented login form — rate limiting and account lockouts make that slow and easy to detect. The overwhelmingly more common real-world attack is credential stuffing: an attacker takes a list of email/password pairs leaked from some unrelated breach and tries those exact same pairs against other sites, banking entirely on people reusing the same password across services.

That's why a unique password per site, generated fresh rather than reused or lightly modified from an old favorite, matters more in practice than squeezing out the last few bits of theoretical entropy from any single password. A password manager that can generate and store a different strong password for every account removes the actual point of failure — human memory forcing password reuse — which is a bigger real-world risk than the entropy math on any individual password.

Some character sets look nearly identical in certain fonts: a capital I, lowercase l and the digit 1 can be indistinguishable; a capital O and the digit 0 the same. An "exclude ambiguous characters" option removes these from the pool specifically to prevent transcription errors when a password has to be typed by hand from a printed sheet or read aloud, rather than pasted directly from a password manager.

This is a small, deliberate entropy trade-off: removing a handful of characters shrinks the pool size slightly, which very marginally lowers entropy per character at a fixed length. In practice that cost is negligible compared to the benefit for any password a human might actually need to type manually — for a password that only ever gets copy-pasted from a manager, there's no reason to enable it at all, since ambiguity only matters when a human eye is reading the characters.

A client-side password generator, like this one, runs entirely in your browser: the password is generated locally using JavaScript's crypto.getRandomValues() and is never transmitted over the network. That's a meaningful privacy guarantee — no server ever sees the password, no logging infrastructure can capture it, and there's no need to trust a third party's security practices. You don't have to assume the server isn't logging its random seed, isn't storing generated passwords, or isn't vulnerable to a data breach that exposes every password it has ever produced.

Server-side generators have their own advantages: they can enforce organization-wide complexity policies (minimum length, required character classes, banned password lists), integrate directly with enterprise password managers and identity providers, and produce passwords in bulk for automated provisioning. For individual use, a client-side generator is the more private choice — just make sure you're using a reputable site over HTTPS and that the page actually runs the generation locally rather than fetching passwords from an API. For enterprise environments where policy enforcement and audit trails matter more than individual privacy, a server-side solution with a trusted identity provider is the better fit.