Password Generator

The source is the operating system, not the clock

Math.random is a deterministic generator wearing a random-looking coat. It starts from a seed — in most engines, a value derived from the time — and every number after that follows from the seed by arithmetic. Read enough output and the internal state can be reconstructed, after which every value it will ever produce is known in advance. It is a fine function for picking a background colour and the wrong one for picking a secret.

This page draws from crypto.getRandomValues, which is the browser's reference to the same source the operating system uses to seed TLS session keys. That source collects entropy from hardware events — interrupt timing, disk latency, unpredictable input — and its output is not derivable from anything previously emitted. The distinction is not about how random the numbers look; both produce a uniform-looking stream. It is about whether an observer holding every previous value can compute the next one. Against the system source, they cannot; the state is never exposed to them.

Why % 62 is biased

The obvious way to turn random bytes into characters is to take a byte, divide by the alphabet size, and keep the remainder. It is also wrong, and the reason is arithmetic rather than philosophy. A byte holds 256 values; an alphabet of 62 does not divide 256 evenly:

256 = 4 × 62 + 8

      byte % 62, over all 256 inputs:
        8 characters of the alphabet can be produced 5 ways
       54 characters can be produced 4 ways

        the 8 are 25% more likely than the other 54

Nothing looks wrong. The output is the right length, drawn from the right characters, and passes every eyeball test. But the distribution has a shape, and a shaped distribution is information an attacker can use — the first character is measurably more likely to be one of those eight. The fix is rejection sampling: draw a byte, and if it falls in the leftover 8 values, throw it away and draw again. Roughly three draws in a hundred are discarded, which costs nothing, and every character left has exactly the same probability as every other.

Coverage, then a shuffle

A requirement to include at least one uppercase letter, one digit and one symbol is a constraint on the result rather than on the drawing. Fulfilling it by placing one of each in the first three positions would put a predictable character at a predictable index, which is worse than the problem it solves. What this page does instead is draw the guaranteed characters, draw the rest freely, and then shuffle the assembled string with the same unbiased source. Every position in the result is equally likely to hold any of the characters.

Constraining the output like this does reduce the entropy slightly, because you have ruled out every string that happens to contain no digit. The entropy readout beside the password accounts for the actual pool and length rather than the theoretical maximum, which is why it is the number worth reading and the coloured strength bar is only a rough translation of it.

One more character, or a wider alphabet?

Given the choice, length wins. Each additional position multiplies the search space by the size of the alphabet; widening the alphabet multiplies each position by a smaller factor. Lowercase alone is 26 characters — 4.7 bits each. Adding the 32 punctuation marks takes the pool to 94, which is 6.55 bits per character: an extra 1.85 bits. An extra lowercase character is worth 4.7, so two more characters beat every symbol you could add, and they are easier to type on a phone.

Symbols earn their place when a system demands them and you will never type the password by hand. They cost you when the password has to be read aloud, entered on a keypad, or stored by a sign-up form written before anyone thought about escaping. When the rules permit a choice, take the length.

Where a generator stops helping

Everything above is about the string, and the string is only one part of the problem. A password generated here and used on six sites is one password, and the first of those six to lose its database has handed it to whoever is holding the file. Reuse is what turns a single breach into an afternoon of account recovery, and no amount of entropy in the string defends against it.

The second limit is the page it is typed into. A random password entered on a phishing site is a random password given away deliberately, and the generator cannot see the difference. Both of these are reasons to keep a manager: it makes a unique string per site the path of least resistance, and it will refuse to fill a form on a host it has not seen before. Use this page to make the password, put it in the vault, and treat the length of the string as the part of the problem it actually is.