Password generator

The number under the meter is entropy in bits, and it measures the generator, not the string it produced. That distinction matters: this tool knows the password was picked uniformly at random from a pool of a known size, so log2(pool^length) is exactly right. A checker looking at a password somebody invented can only guess, and will happily award "Summer2024!" a score it has not earned. The estimated guessing time assumes an offline attack at ten billion guesses a second, which is roughly one modern GPU against a poorly-hashed database, pessimistic on purpose.

The character sets are what let one form do the work of several, and the PIN mode is the same idea made explicit: digits only, three to twelve of them, leading zeros kept. That last part matters more than it sounds, because a generator that quietly drops a leading zero removes a tenth of the possible values from a four-digit PIN. Human PINs cluster hard — 1234, 1111, 0000 and four-digit years beginning 19 cover a startling share of every PIN in real use — so drawing one is worth the two clicks. A PIN is weak by construction either way: four digits is ten thousand possibilities, fine where something limits the attempts and useless anywhere an attacker guesses freely.

At the other end, a secret only a machine has to read can be as long and ugly as you like. The usual target for an API key or a session token is 128 bits, which twenty characters from the full pool clears with a little to spare. Letters and digits only if the value has to survive a URL or a shell without escaping; the symbol set is the part that causes trouble in transit. The named alphabets do that job explicitly: hex carries four bits a character, base32 five, base58 and base62 just under six, and a version 4 UUID a fixed 122 however you slice it. Thirty-two hex characters is the 128-bit target written the way most APIs expect to receive it, and base58 is the one to reach for when a person has to read the value out, since it leaves out 0, O, I and l.

Words are the same arithmetic one level up, and they are the mode for the handful of passwords you type by hand instead of pasting. Each word is log2 of the list size: this page draws from about 48,500 English words of four letters and up, which is 15.5 bits each, so five words is roughly 78 bits and six is 93. Diceware built the idea around a 7,776-word list and physical dice at 12.9 bits a word; the draw here is the same procedure with crypto.getRandomValues in place of the dice, which is only a downgrade if your threat model distrusts the machine you are sitting at. What a phrase buys is recall, not strength — 78 bits from five words is 78 bits, no better than thirteen random characters — and the separator and the capitals add nothing an attacker does not already assume, because both are fixed transforms that anyone generating candidates applies too. The trailing number is the exception and the meter counts it: it is drawn at random from 10 to 99, which is a genuine log2(90) — about 6.5 bits, taking five words from 78 to 84 and the band from strong to excellent. A number you choose yourself is worth far less than that, which is the whole difference.

Length is almost always the cheaper lever. Going from 62 characters in the pool to 87 buys about half a bit per character, where four extra characters buy nearly twenty-four. That is why current NIST guidance raises the minimum length and drops composition rules, and not the other way round.