Where the randomness comes from.

Two kinds of random

A computer cannot roll dice. What it can do is run a formula that produces a long stream of numbers that look random, starting from a seed. That is a pseudo-random number generator, and JavaScript's Math.random() is one. It is fast and fine for shuffling a playlist or picking a colour, but it was never designed to resist someone who wants to predict it. Given a few outputs, the internal state of the common implementations can be recovered and the next values worked out. For a password that is disqualifying.

The second kind is a cryptographically secure generator. It is still a formula, but it is seeded and continually re-seeded from real physical noise the operating system collects: timing jitter between keystrokes and disk operations, network arrival times, dedicated hardware in the processor. Its design goal is that even someone who has seen every previous output cannot predict the next one. In the browser this is exposed as crypto.getRandomValues(), part of the Web Crypto API, and it is what every generator here uses.

From 32 bits to a die

Web Crypto hands out raw bytes, or 32-bit numbers from 0 to 4,294,967,295. A generator needs something smaller: a digit from 0 to 9, a character index out of 85, a lottery ball from 1 to 69. The obvious way to get there is to take the big number and keep the remainder after dividing by the range you want. It is the obvious way and it is subtly wrong.

The modulo bias

Say you have a source that gives you 0 to 9, and you want a number from 0 to 3. Taking the remainder after dividing by four maps 0, 4 and 8 to zero; 1, 5 and 9 to one; 2 and 6 to two; and 3 and 7 to three. Zero and one each get three of the ten inputs, two and three get only two. The low results are half again as likely as the high ones. With a 32-bit source and a small range the skew is tiny, but it is real, and for anything that claims to be uniformly random it is a flaw an attacker can measure.

Rejection sampling

The fix costs almost nothing. Work out the largest multiple of your range that fits in the source, and if the source produces a value at or above that limit, throw it away and draw again. In the example, the limit is 8: values 8 and 9 are rejected, and the remaining 0 to 7 map to 0 to 3 exactly twice each. Every outcome is now equally likely. With a 32-bit source the rejected slice is a sliver, so a redraw is rare and the cost is invisible. Every range on this site, from a digit to a lottery pool, is drawn this way.

Drawing without repeats

A lottery line needs several different numbers from one pool. Drawing repeatedly and skipping duplicates works but is wasteful when the pool is small. The cleaner method is a partial shuffle: imagine the pool laid out in order, swap the first position with a randomly chosen one, then the second with a random one from the rest, and so on for as many picks as you need. Each pick is uniform over what remains, and no number can appear twice. The generators here use exactly that, without ever building the full list, so it works for a pool of 80 and a pool of a million alike.

Where it runs

All of this happens on your device. The page never asks a server for a random number, and never tells one what it produced. Web Crypto is available in every modern browser, and if it were somehow missing the generator would fall back to Math.random() and say so in the source line under the output, rather than pretend. In practice that fallback has not been needed for years.

What randomness cannot do

A perfectly random password is only as safe as where it is stored afterwards. A perfectly random lottery line has exactly the same chance as any other line, including 1 2 3 4 5 6, and is no more likely to win. Randomness guarantees that nobody can guess better than chance. It does not change what chance is.

See it in action in the Password Generator, the PIN Code Generator and the Lottery Number Generator, and read how the number of possibilities turns into a strength score in Password entropy, explained.