Password Generator

Length beats character variety, and the maths says so

The numbers are arithmetic, not opinion. With all four sets on, the pool is 87 characters: 26 uppercase, 26 lowercase, 10 digits and 25 symbols. Each character therefore carries log₂(87) = 6.44 bits. With only lowercase on, the pool is 26 and each character carries 4.70 bits. That 1.74 bits is the entire difference between the two extremes.

Read the first and last rows together: 22 lowercase letters carry 103 bits, the same as 16 characters drawn from all four sets. Six extra keystrokes replace every symbol, digit and capital. So when a password feels unwieldy, drop the symbols and add length rather than the other way round.

Crack times, with the assumption stated out loud

Every "time to crack" figure rests on a guess rate that usually goes unmentioned. Here is ours, and it is an assumption rather than a measurement: assume an attacker who already has the stolen password hash and can test 10¹² candidates per second offline, finding it on average halfway through the space — so 2^n-1 guesses for an n-bit password.

Change the assumed rate and every row moves with it: a rate a thousand times higher shifts each figure down a thousandfold, which is the same as losing about 10 bits of length. Note what that does and does not change. The 6-character row is hopeless under any assumption; the 20-character row is absurd under any assumption you could defend. Only the middle rows depend on the guess rate, and that is the summary of the whole argument.

Two caveats. The table assumes offline guessing against a stolen hash; an online login form with rate limiting is a far smaller problem. And it assumes the site stored your password with a slow modern hash — if it stored it in plain text, none of this was ever the weak link.

Where the randomness comes from, and two caveats

A generator is only trustworthy if its randomness is unpredictable. This one draws from crypto.getRandomValues, the browser's cryptographically secure source, seeded from a high-quality entropy source such as the operating system's. It does not use Math.random, whose output is fine for shuffling a carousel but, in MDN's words, does not provide cryptographically secure random numbers. Two limitations, stated because you should not have to take the claim on faith.

1. There is a modulo bias, and it is minuscule

Each character comes from a 32-bit random value reduced with a remainder. 2³² is 4,294,967,296, and 87 × 49,367,440 = 4,294,967,280, leaving 16 spare. So the first 16 characters of the pool are each produced by 49,367,441 of the possible draws while the rest get 49,367,440 — an excess of about one part in 49 million. A genuine deviation from uniform, and far too small to move any figure above.

2. No character class is guaranteed to appear

Each position is drawn independently from the combined pool, so a 16-character password with all four sets on may legitimately contain no symbol. The chance is (62/87)¹⁶ ≈ 0.0044, about 1 in 226. When a site insists on a symbol, press Generate new again. Do not hand-edit a ! onto the end: that is the most common way people quietly demolish the randomness they just paid for, because everyone puts it in the same place. For the same reason, take the first result that satisfies the rules instead of scrolling for one that looks nicer — human taste is a pattern.

The exact character sets, and what the labels mean

The symbol set is precisely these 25 characters: !@#$%^&*()-_=+[]{};:,.<>?. Absent are the space, backslash, forward slash, both quote marks, the pipe, tilde and backtick — the ones most likely to be rejected by a login form or mangled by a shell. Deliberately conservative, which helps when the password must survive being pasted somewhere awkward.

There is no "avoid lookalikes" switch, so l, I and 1 can appear together, as can O and 0. Irrelevant when you paste, painful when reading a password aloud or typing it with a TV remote; for those cases, symbols off and more length.

The Strength label comes from the entropy figure alone: under 64 bits Weak, under 80 Good, under 120 Strong, 120 or more Very strong. It describes how the password was made, not how it looks — the same eight letters typed by hand carry nothing like 52 bits, because you did not choose them uniformly at random.

What this page is not

It is not a password manager and it stores nothing: no history, no list, no recovery. Reload and the password is gone for good, so open the vault entry first, then generate and paste. A strong password you cannot reproduce is an account you cannot reach.

It is not a passphrase generator either: no word list, so it makes character strings rather than four-random-words. Both are sound; this is simply not the other. Nor is it a source of key material for software — for identifiers use the UUID generator, for digests the hash generator, and in real code derive keys with a purpose-built KDF. If you want arbitrary random text with your own alphabet, the random string generator fits better. And encoding is not protection: Base64 is reversible by anyone, instantly, by design.

Why it matters that this one runs locally

A password that crossed a network before you ever used it is not a secret. A generator that builds the string on its server puts your future credential in that server's access log, in whatever proxy sits in front of it, and permanently in the operator's backups. None of that requires bad faith — ordinary logging is enough.

Here the string is assembled by your own browser from your own machine's entropy. The script has no fetch, no XMLHttpRequest and no beacon, and the proof takes ten seconds: load the page, turn off your Wi-Fi, keep generating. What still leaves the page is what you do next — copying puts the password on the system clipboard, where other apps may be able to read it (phones restrict this more than desktops), and it stays on screen until you navigate away. Paste it into your manager promptly, and think twice about generating one while your screen is shared. The rest of this family is on the generators page.