Password Generator

A password generated on someone else’s server has, by definition, been seen by someone else’s server. That is not a hypothetical risk to weigh against convenience — it is what the words mean. This page makes no network requests at all, and there is an assertion in our test suite that fails the build if one ever appears.

The problem with generating passwords remotely

It is worth being precise about what goes wrong, because the usual framing — “they probably do not store it” — misses the point. When a server produces your password, that password exists in that server’s memory, quite possibly in a request log, plausibly in an error report, and certainly in the process of at least one machine you do not control. Whether anybody looks is a question about their intentions and their security. Whether it was exposed is not a question at all.

The same reasoning applies to browser extensions that phone home, and to generators that fetch “true randomness” from a remote entropy service. There is no randomness shortage in your own machine that would justify the trade: every modern operating system maintains an entropy pool seeded from hardware, and your browser exposes it directly through crypto.getRandomValues.

This page has no server side to speak of. It is static HTML and JavaScript; the generation happens in your tab; the result exists only there until you copy it. Confirm it in about ten seconds: open developer tools, switch to the Network tab, and generate as many passwords as you like. The list stays empty. The site’s Content-Security-Policy also restricts connections to its own origin, so your browser would block an attempt even if our code made one.

Entropy, and the arithmetic most generators get wrong

Entropy measures how many equally likely passwords the generator could have produced, expressed in bits. For a password drawn uniformly from a pool of characters, it is the length multiplied by the base-two logarithm of the pool size. Twenty characters from a pool of eighty-eight is a little over one hundred and twenty-nine bits, which is far beyond what any offline attack can reach.

Here is where a lot of tools quietly break their own claim. Almost all of them offer “at least one of each character type”, because websites demand it. The common implementation places one character from each class, fills the rest at random, and shuffles. The result is no longer uniform over the constrained set — some arrangements are more likely than others — so the entropy is not what the tool reports, and the number on screen overstates the strength of the password it just produced.

This page handles it differently. With the constraint switched on, whole candidates are generated and rejected until one satisfies it. Rejection sampling keeps the distribution exactly uniform over valid strings, so the entropy is the base-two logarithm of the number of valid strings — and that count is computed exactly by inclusion–exclusion over the character classes rather than estimated. The figure shown drops by a small fraction of a bit when you enable the constraint, and that reduction is real. A tool whose entropy figure does not move when you add a constraint is not measuring the password it gave you.

Length beats complexity, and it is not a close contest

Entropy grows linearly with length and only logarithmically with the size of the character set. Adding one character to a twenty-character password from an eighty-eight-character pool adds about six and a half bits. Doubling the pool from eighty-eight to one hundred and seventy-six characters — which is not even possible with printable ASCII — would add one bit per character. Length is the lever.

This is why the old advice about mixed case, digits and a symbol produced such poor results in practice. It pushed people towards short passwords stuffed with substitutions, which are hard to remember and only marginally harder to guess, because attackers model those substitutions. Current guidance from NIST reflects this: minimum lengths matter, composition rules are discouraged, and forced periodic rotation is discouraged too because it drives people towards predictable increments.

For anything you actually have to type from memory, a passphrase of several random words is easier to remember at the same entropy and much easier to transcribe. For everything else — which should be nearly everything — use a password manager and let entries look like the output of this page. You never type them, so their unmemorability costs you nothing.

Look-alike characters, and why there is no download button

The option to skip look-alikes removes capital I, lowercase l, the digit one, the pipe, capital O, the digit zero and lowercase o. It costs a fraction of a bit of entropy per character and it prevents a specific, common failure: a password that has to be read off a screen, dictated over a phone, or copied from a printed sheet, and is transcribed wrongly. A password you cannot enter correctly is worse than one that is very slightly shorter.

You will notice there is no download button on this page, and that is deliberate rather than missing. Writing a freshly generated password into a plain text file in your downloads folder puts it somewhere it will be forgotten, somewhere it is likely to be synced to cloud storage, and somewhere any process on your machine can read it. Copy it straight into a password manager instead. The clipboard is not perfect either — other applications can read it, and it may persist — so paste it into its destination promptly rather than leaving it sitting there.