Why crypto.getRandomValues() and not Math.random()
Math.random() is designed for things like games and animations — fast, but not built to resist prediction. Depending on the browser's implementation, someone who observes a handful of its outputs can sometimes predict future ones. crypto.getRandomValues(), part of the Web Crypto API, is built for exactly this use case: it draws from the operating system's cryptographically secure random number generator, the same class of source used to generate encryption keys. This tool relies on it exclusively — if the Web Crypto API isn't available, generation is disabled rather than silently falling back to a weaker source.
Character selection also uses rejection sampling rather than a plain modulo operation, to avoid a small but real statistical bias: naively mapping a 32-bit random number onto a character pool with random % poolSize very slightly favors whichever characters land in the "remainder" region, since 2³² is essentially never an exact multiple of the pool size. The bias this avoids is small — not something that would make a generated password meaningfully easier to guess — but a tool that claims uniform randomness should actually be uniform.
How length and character sets affect entropy
Entropy here is a straightforward calculation: length × log2(pool size), where the pool size is how many distinct characters the generator is choosing from. Adding a character type (say, symbols) increases the pool size, which increases entropy per character — but adding length has a compounding effect, since every additional character multiplies the number of possible passwords rather than just adding to a total. In practice, a longer password with fewer character types often beats a shorter one stuffed with every type available.
The "estimated average brute-force time" below assumes an attacker checking the keyspace in random order finds this specific password after checking about half of it on average — at an assumed 10 billion guesses per second, a number we show explicitly because it's a real assumption, not a universal constant. Actual attack speed depends heavily on how a password is stored (a slow, salted hash can be many orders of magnitude harder to attack than a fast, unsalted one), the attacker's hardware, and whether the attack is even feasible offline at all. Treat the estimate as a rough, comparative signal — useful for judging "is this meaningfully stronger than that," not as a literal guarantee.
Because this tool's output is cryptographically secure and uniformly sampled (unlike a password a person invents, which usually carries hidden patterns), the entropy figure shown is the theoretical search-space entropy for the selected pool and length — no pattern-matching discount needed, unlike our Password Strength Checker, which has to account for the fact that human-chosen passwords are rarely as random as they look.
Frequently asked questions
Is this actually more secure than a password I make up myself?
Almost always, yes. People are bad at being random on purpose — predictable substitutions, keyboard patterns, and reused structures are what make human-created passwords crackable. A generated password has no structure to exploit, only brute-force guessing across the full character space.
What length should I use?
16 characters with all four character types is a reasonable default for most accounts today. For anything protecting particularly sensitive access (a password manager's master password, an email account used for account recovery), consider 20 or more.
I checked all four character types but got a password with no symbols. Is that a bug?
No — each checkbox controls which characters are allowed, not which are guaranteed. With every type allowed, it's still possible (just not likely) for chance to skip one entirely, the same way you can flip a coin ten times and never get tails. If a site strictly requires a symbol, click Generate again.
Does turning on "avoid ambiguous characters" hurt security?
It reduces the character pool slightly (removing 0, O, 1, l, I), so entropy per character drops a little — but the entropy readout updates live, so you can compensate by nudging the length up if it matters for your use case. It exists for situations where a human has to actually type or transcribe the password, not for automated storage in a password manager.
Can you see or log the passwords I generate?
No — the generated password value is processed locally and is never included in any network request made by this generator. The page itself loads normally (fonts, scripts, and so on both use the network, like any web page), but the password text specifically never leaves your device unless you paste it somewhere yourself. If you're not sure where the rest of your habits stand, our Cyber Hygiene Quiz takes about a minute and flags the biggest gaps.
Last reviewed: . Methodology: passwords are generated via the Web Crypto API's crypto.getRandomValues(), with rejection sampling for uniform character selection (see "Why crypto.getRandomValues()" above).