Password Generator

Where the randomness comes from

Generation uses the browser's crypto.getRandomValues, which draws from the operating system's cryptographically secure random number generator. This is the same class of source used for key material, and it is unpredictable even to someone who knows every previous output.

That distinction matters. The ordinary Math.random found in most simple generators is not cryptographically secure -- its output is predictable given enough samples, and it should never be used for anything that protects an account.

Avoiding modulo bias

Converting random bytes into characters naively, by taking the remainder against the alphabet size, makes early characters in the set slightly more likely than later ones. The effect is small but it measurably reduces entropy.

This generator uses rejection sampling instead: bytes falling in the uneven tail of the range are discarded and redrawn, so every character is exactly equally likely. It costs a negligible number of extra draws and produces a genuinely uniform result.

Why some characters are excluded

The alphabet omits l, I, 1, O and 0. Those are the characters people confuse when reading a password aloud or copying it by hand, and the confusion causes far more lost time than the handful of excluded characters costs in entropy.

If you never type passwords manually -- because a password manager fills them -- the exclusion is unnecessary, but it is harmless. Add two characters of length and you have more than recovered the difference.

Choosing a length

Sixteen characters is a sensible floor for anything that matters, and twenty or more for accounts protecting money, email or infrastructure. Email deserves particular care: whoever controls it can reset most of your other accounts.

Some systems still impose maximum lengths or forbid symbols, which usually indicates the password is being stored badly. Where you have a choice, generate the longest the system accepts.

A strong password is not the whole defence

Strength only protects against guessing. It does nothing about the way credentials are actually lost most often, which is reuse: one breached site hands attackers an address and a password, and those get replayed against every other service until something opens. A twenty-character password reused in three places is weaker in practice than three ordinary ones that are unique, which is the real argument for generating a fresh one per account rather than inventing a memorable scheme.

Second-factor authentication covers what a password cannot. If a password does leak -- through a breach, a convincing phishing page, or a keylogger -- the second factor is what stands between the attacker and the account. Enable it on email first, then on anything holding money or infrastructure access, and prefer an authenticator app or a hardware key over SMS where the option exists.

Scheduled rotation is the practice worth dropping. Forcing changes every ninety days pushes people toward predictable variations, and current guidance from NIST advises against it. Change a password when there is a reason to -- a breach notification, a shared credential, a departing colleague -- and otherwise leave a strong unique one alone.