Strong Password Generator

How this generator works

Every password on this page is created by JavaScript that is already loaded in your browser. There is no server call, no queue and no account: when you move a slider or press Regenerate, the relevant code runs on your own machine and the result is written straight into the page. If you open your browser's network panel while using the tool, you will see no request carrying your password, because none is made.

The random characters come from crypto.getRandomValues(), the browser's cryptographically secure random number generator, which is the same class of source used for TLS session keys and other security-critical values. It is deliberately not Math.random(), which is a fast but predictable pseudo-random generator whose internal state can be reconstructed from a handful of outputs — fine for animation jitter, unacceptable for secrets.

Secure randomness alone is not enough, because of a subtle trap called modulo bias. If you take a random 32-bit integer and compute n % poolSize, the first few characters of the pool come up slightly more often than the last ones whenever poolSize does not divide the range of n exactly. The bias is tiny per character, but over a 20-character password it quietly shrinks the search space. This generator uses rejection sampling instead: it draws a random 32-bit value, keeps only values below the largest multiple of the pool size, and throws the rest away. The discarded values are re-drawn, never folded, so every character in the pool has exactly the same probability.

A related detail is the "require at least one of each selected set" option, which is on by default. Purely random strings occasionally contain no digits and no symbols at all, and a great many websites reject them. When that option is enabled, the generator first draws the full password at random, then guarantees that at least one character from each selected set is present and removes the overlap. The guarantee costs a fraction of a bit of entropy, which the meter accounts for.

Password length is the biggest lever

Entropy, measured in bits, is the standard way to describe how hard a password is to guess. For a password drawn uniformly from a pool of A distinct characters with length L, the number of possible passwords is A^L, and entropy is its base-2 logarithm:

bits = L × log2(A)

16 characters from 94 symbols  → 16 × 6.554 = 104.9 bits
12 characters from 94 symbols  → 12 × 6.554 =  78.6 bits
16 characters from 26 letters  → 16 × 4.700 =  75.2 bits

Because length multiplies and the alphabet only contributes a logarithm, adding characters beats adding symbols almost every time. Each extra character from a 94-character pool adds about 6.55 bits, which doubles the guessing effort every time you add roughly a sixth of a character — in practice, every one or two characters you add multiplies an attacker's work by tens or hundreds. Widening the alphabet from 26 to 94 characters only adds about 1.85 bits per character, and you can only widen it so far.

The meter on this page converts entropy into a crack-time estimate at 10 billion guesses per second. That figure is generous to the attacker: it represents a determined offline assault using modern GPUs against a fast hash. On the other side of the ledger, real services rate-limit log-in attempts, hash passwords slowly, and lock accounts, so the practical time is usually far longer. Treat the number as a worst case, not a best case.

Notice how compressed the bottom of that table is. The difference between "cracked in a second" and "cracked in a century" is not a factor of a hundred; it is a factor of about 3 billion, and it is usually reached by moving from eight characters to eighteen.

Choosing a character set

The four sets on this page have very different sizes, and the size of the pool is what feeds the logarithm in the entropy formula:

• Lowercase (26) — the baseline. Readable and easy to type on any keyboard layout.
• Uppercase (26) — adds 26 possibilities, about one extra bit per character.
• Digits (10) — only 10 extra possibilities, but many sites insist on them.
• Symbols (32 here) — a useful top-up, and often the set that satisfies a stubborn password policy.

All four together give a pool of 94 characters and 6.55 bits per character. If a site rejects symbols, dropping to 62 characters loses only about 0.6 bits per character — recover it by adding a single character to the length. The one genuinely useful subtraction is excluding look-alike characters. The letters I, l and the digit 1, or the letter O and the digit 0, are the source of most transcription errors when a password is read off one screen and typed into another. Removing them costs about 0.4 bits per character and removes a whole category of support tickets. The exclude characters field goes further: paste in any characters your target system refuses — or ones that are awkward on a phone keyboard — and they are struck from the pool before generation.

Two counter-intuitive points are worth stating plainly. First, symbols are not magic; they are simply more characters, and length buys more of them. Second, complexity rules that force one upper, one digit and one symbol into a short password do very little; the same rules applied to a 20-character password do not matter at all because it is already unguessable. Length first, then the alphabet.

Passphrases vs random strings

A passphrase trades some entropy per character for something random strings cannot offer: memorability and typeability. This tool ships with an embedded list of 2392 common English words of four to eight letters, which gives about 11.2 bits per word (log2 2392 ≈ 11.22). The meter uses that number for passphrase entropy, then adds the contribution of any appended digits (3.32 bits each) and symbols (3 bits each).

4 words → 4 × 11.2  = 44.9 bits   (fair: only for low-value log-ins)
5 words → 5 × 11.2  = 56.1 bits   (fair)
6 words → 6 × 11.2  = 67.3 bits   (strong)
8 words → 8 × 11.2  = 89.8 bits   (very strong)

Compare that with a 16-character random string at roughly 105 bits. To reach the same figure with words you would need eleven of them, which is a lot to type. The honest conclusion is that words win when a human has to remember and retype the secret — a device unlock code, a master password you type daily, a Wi-Fi key — and random strings win when software does the typing. Since a password manager types for you, the default here is a random string. Where a service forces you to memorise something, switch to passphrase mode, pick six or more words, and keep the separator consistent so it stays easy to retype.

One warning about passphrases is easy to overlook: they are only strong if the words are chosen randomly. Human word choices cluster heavily around a small favourite set, which is exactly what cracking tools exploit with dictionary and rule-based attacks. Let the generator pick the words; never assemble them yourself.

What to do with the password you just generated

1. Put it into a password manager immediately. The few seconds between generating a password and saving it are when it gets lost — pasted into a chat window, lost in a closed tab, or replaced by something weaker because you were tired. Save first, then paste.
2. Never reuse it. Credential stuffing works because one breach leaks an email and password pair, and attackers replay that pair against hundreds of other sites. A password you reuse is effectively one password shared across every account it protects; the strength of the individual string stops mattering once it appears in a breach dump.
3. Turn on two-factor authentication for email, banking and anything holding payment details. A strong password and a second factor cover different attacks, and together they are far more than the sum of their parts.
4. Change it only if it is exposed. Modern advice is against rotating passwords on a schedule — forced rotation produces predictable variations like Summer2026!. Change a password when a breach notification, a suspicious log-in or a shared computer gives you a reason.
5. Check the password against breach lists where a service offers it, and prefer the longest value a site accepts. If a site caps you at twelve characters, that is a reason to enable two-factor authentication rather than to look for a different string.