Use a password manager
This is the part of the page that matters, so it goes first rather than at the bottom as a footnote. Almost every account compromise that starts with a password starts with a password that was reused somewhere else. A service gets breached, the credentials appear in a dump, and someone tries the same email and password against a few hundred other sites. The strength of the password is irrelevant to that attack. Its uniqueness is the only thing that matters.
A password manager solves that by making uniqueness free. It generates a different random string per site, stores it, fills it in, and you never see or type it. The Passwords app built into Apple devices and Google Password Manager are already on hardware most people own and cost nothing. Bitwarden is free across every platform, 1Password is paid and well made. Any of them beats a system you maintain by hand.
Generating a password on a web page is fine for what it is: something to paste into a manager, a wifi key, a service account credential, a one-off. It is not a substitute for the manager. If you take one thing from this page, take that.
How these are generated
Each password is drawn from crypto.getRandomValues, which the browser fills from the operating system entropy pool — the same source that seeds TLS. It is not Math.random(), which is a fast statistical generator with no security claim at all and, in some engines, state that can be recovered from a handful of outputs.
Reducing a 32-bit random value into a range needs care. Taking the remainder modulo the alphabet size is the obvious approach and it is subtly wrong: 2³² is not divisible by 62, so the first few characters of a 62-character alphabet come up very slightly more often than the rest. The bias is tiny at these sizes, and it is also completely avoidable, so this page uses rejection sampling instead. Any draw landing in the incomplete final block is thrown away and a new one taken, which makes the distribution exactly flat.
One character from each selected set is placed first, the rest is filled from the combined alphabet, and the whole thing is shuffled with a Fisher-Yates pass using the same generator. The guaranteed-one-of-each step exists because sites demand it, and it costs a negligible amount of entropy compared to a purely uniform draw.
Length beats complexity
Entropy in bits is the length multiplied by the base-2 logarithm of the alphabet size. That formula tells you where to spend effort, because length is a multiplier and alphabet size sits inside a logarithm.
| Password | Alphabet | Entropy |
|---|---|---|
| 8 characters, all four sets | about 75 | 50 bits |
| 12 characters, lowercase only | 26 | 56 bits |
| 16 characters, letters and digits | 62 | 95 bits |
| 20 characters, all four sets | about 75 | 125 bits |
Twelve random lowercase letters beat eight characters of mixed everything, and are far easier to type on a phone. Adding symbols to a 16-character password moves it from 95 to about 100 bits, which changes nothing an attacker can exploit. Adding four characters moves it from 95 to 119. Below about 50 bits a well-funded offline attack against a fast hash is realistic; above 70 it is not; above 100 the number stops meaning anything physical. These figures assume the attacker knows your exact generation settings, which is the correct pessimistic assumption.
When a site will not accept it
Length caps and symbol bans are still common and are generally a sign that the password is being stored in a way it should not be. You cannot fix that from outside, but you can compensate. Turn symbols off and add characters: 20 characters of letters and digits is about 119 bits, comfortably more than 12 characters of everything. If the cap is on length rather than the character set, use every character it allows and rely on the manager for uniqueness.
Leave the look-alike exclusion on when the password has to survive a human — read down a phone line, typed off a sticky note, entered on a television remote. It removes l, 1, I, O, 0 and o, which costs about five characters of alphabet and around three bits on a 20-character password. That is a good trade against typing it wrong four times. Turn it off when the password only ever moves by copy and paste.
Questions people ask
Are these passwords stored or sent anywhere?
No. The generation runs entirely in the page, the values exist only in the browser tab, and leaving or reloading the page destroys them. There is no network request involved and you can confirm that yourself: open the network tab in developer tools, press Generate, and watch nothing happen. The site has no account system and no server-side logging of form contents. That said, the right level of trust in any claim like this one is limited, which is the practical reason to prefer a password manager generating locally on your own device over any web page, including this one.
Should I use a passphrase instead?
For anything you have to type from memory, yes. A passphrase of six words chosen at random from a 7,776-word list carries about 77 bits, comparable to a 12-character random string, and it is far easier to remember and to type on a phone keyboard. The condition is that the words are chosen randomly, by dice or by software — a phrase you compose yourself is a sentence, and sentences have grammar, which is structure an attacker can search. The realistic split is a passphrase for your device login and your password manager master password, and generated random strings for everything else, since you never type those anyway.
How often should I change passwords?
When there is a reason, not on a schedule. NIST withdrew the periodic-expiry advice years ago after the evidence showed what it actually causes: people take a password they can remember and add a number to the end each quarter, which is worse than leaving it alone. Change a password when a service reports a breach, when you have any reason to think it has been exposed, when it was ever reused elsewhere, or when someone who had access should not any more. Otherwise a long unique random password is doing its job, and rotating it only creates opportunities to write it down.
What does the entropy figure actually mean?
It is the base-2 logarithm of the number of passwords the generator could have produced with the settings you chose, so 100 bits means one in 2^100. It assumes the attacker knows the settings exactly — the length, the sets, whether look-alikes were excluded — and is guessing uniformly across everything you could have got. That is the correct pessimistic assumption and it is what makes the number honest. Note that it says nothing about how the password is stored at the other end. Against a site hashing with bcrypt or Argon2, 70 bits is untouchable; against a site storing plaintext, no number helps.