Password Generator
Runs on your device. Nothing is sent.Everything happens on your own device. Nothing you generate is ever sent anywhere.
Strength
Very strong103.4 bits of entropyEstimated time to crack: 205B centuries
Generate strong random passwords and memorable passphrases, with a live entropy and crack-time estimate, entirely in your browser.
A password's real strength comes from entropy - how many possible passwords an attacker would have to try before guessing yours - which depends on both length and how many different characters could appear at each position. This tool generates cryptographically random passwords (via the Web Crypto API, not Math.random()) or word-based passphrases, and shows the actual entropy and a rough crack-time estimate for whatever you generate, so the trade-offs are visible rather than hidden behind a vague "strong/weak" label. Nothing is generated on a server or sent anywhere.
Frequently asked questions
Should I use a random password or a passphrase?
Both are legitimate, and the 2024 NIST digital identity guidelines explicitly favor length over forced complexity rules. A random password packs more entropy per character, which is ideal when a password manager will remember it for you. A passphrase - several random words strung together - trades a bit of entropy per character for something a human can actually memorize and type, which matters for master passwords or anything you type from memory.
What does 'bits of entropy' actually mean?
Each additional bit of entropy doubles the number of guesses an attacker would need to try every possibility. A password with 40 bits of entropy has about a trillion possible combinations; one with 80 bits has about a trillion times a trillion. Security guidance generally treats 80+ bits as excellent for anything you can't put behind rate-limiting or lockouts, like an encryption key or a password manager's master password.
How is the crack-time estimate calculated?
It assumes an attacker with offline access to a password hash, guessing at roughly 10 billion attempts per second - a rough stand-in for a modern GPU cluster. It's meant to communicate order of magnitude, not a precise forecast: real crack time depends heavily on the hashing algorithm the target system uses, which this tool has no way of knowing.
Why exclude ambiguous characters like l, 1, I, O, and 0?
They're easy to mix up when read aloud, handwritten, or displayed in certain fonts. Excluding them trades a small amount of entropy for a password that's less error-prone to type from a screen or a piece of paper - useful for passwords you'll need to enter manually rather than paste from a manager.
Could the random generator favor certain characters over others?
No - it uses rejection sampling on top of crypto.getRandomValues() rather than a simple modulo operation. Taking a random byte and doing byte % poolSize would give characters near the start of the pool very slightly better odds whenever the pool size doesn't evenly divide 256, so the generator instead discards any out-of-range value and draws again until the result lands in a range that divides evenly. The result is that every character has exactly the same probability of being chosen, no matter how many character types you enable.
Why does a random password always include at least one of every character type I enabled?
After building the character pool, the generator sets aside one character from each category you've turned on - uppercase, lowercase, numbers, symbols - before filling the rest of the length from the full pool, then shuffles everything into a random order. That guarantees your password won't accidentally end up all letters with no digit, which matters because many sites reject a password missing a required character type even though the pool included one. The shuffle step uses the same unbiased random selection, so the guaranteed characters don't end up in predictable positions.