Password generator

Where the randomness comes from

Every character is drawn from crypto.getRandomValues, the Web Crypto API’s cryptographically secure random number generator. It is seeded by your operating system’s entropy pool - hardware sources, timing jitter and other unpredictable input - and it is the same primitive used to generate TLS session keys.

Math.random is deliberately never used. It is fast, it is not seeded securely, and its output is predictable from a handful of observed values. It is fine for shuffling a playlist and unfit for anything protecting an account.

Why the sampling method matters

Turning a random 32-bit number into a character in a 94-character alphabet has an obvious wrong answer: random % 94. Because 2³² is not divisible by 94, the low-numbered characters come up slightly more often than the high-numbered ones. The bias is small, but it is a bias in exactly the place where uniformity is the whole point.

This generator uses rejection sampling instead. Values landing in the uneven tail are discarded and redrawn, so every character in the alphabet is exactly equally likely.

It also guarantees at least one character from each enabled set, without stacking them at the front: the required characters are drawn first, the remainder fills from the whole alphabet, and the result is shuffled with Fisher–Yates.

Entropy, in numbers

entropy (bits) = length × log₂(alphabet size)

Length	Lowercase only (26)	Letters + digits (62)	All sets (94)
8	37.6 bits	47.6 bits	52.4 bits
12	56.4 bits	71.5 bits	78.7 bits
16	75.2 bits	95.3 bits	104.9 bits
20	94.0 bits	119.1 bits	131.1 bits

A useful reference point: 128 bits is the standard target for cryptographic keys. Anything at or above it is not going to be brute-forced by anyone, ever.

Notice that a 16-character lowercase password (75 bits) beats a 12-character password using every symbol class only marginally - and beats an 8-character one using every class comfortably. Length is the cheaper lever than complexity, and it is the one humans tolerate better.

What entropy does not protect against

A perfectly random password is worthless if it is reused. Credential-stuffing attacks do not guess passwords; they replay ones already leaked from another breach. Strength protects against brute force, uniqueness protects against reuse, and only a password manager gives you both at scale.

Nor does entropy help if the password is phished. Enable two-factor authentication wherever it is offered - preferably an authenticator app or hardware key rather than SMS, which is vulnerable to SIM-swap.

Modern guidance

NIST’s SP 800-63B reversed decades of received wisdom. It now recommends against mandatory periodic password changes, and against forced composition rules like “must contain a symbol”. Both push people toward predictable patterns - Password1! becoming Password2!. What it recommends instead is length, a check against known-breached password lists, and no arbitrary maximum length.