Password strength is measured in bits of entropy, and for a randomly generated password it is exact:
bits = length × log2(alphabet size)
Each bit doubles the search space. Adding one character to a 95-symbol password adds about 6.6 bits, which multiplies the work by 95. Here is what each alphabet buys per character:
| Alphabet | Size | Bits per character |
|---|---|---|
| Lowercase only | 26 | 4.70 |
| Upper and lower | 52 | 5.70 |
| Alphanumeric | 62 | 5.95 |
| All printable ASCII | 95 | 6.55 |
| Length | 26 chars | 62 chars | 95 chars |
|---|---|---|---|
| 8 | 37.6 bits | 47.6 bits | 52.4 bits |
| 12 | 56.4 bits | 71.5 bits | 78.7 bits |
| 16 | 75.2 bits | 95.3 bits | 104.9 bits |
| 20 | 94.0 bits | 119.1 bits | 131.1 bits |
Assume an offline attack — the attacker has stolen a database and is guessing locally at a trillion candidates per second, which is realistic for a GPU rig against a fast, badly chosen hash. On average half the space must be searched.
| Password | Entropy | Average time to crack |
|---|---|---|
| 8 random printable ASCII | 52.4 bits | about 49 minutes |
| 12 random printable ASCII | 78.7 bits | about 6,000 years |
| 16 random printable ASCII | 104.9 bits | about 640 billion years |
The lesson is the shape of the curve, not the headline numbers. Eight characters is finished within a working day even with every symbol class included. Sixteen is not a matter of waiting for faster hardware — the gap is around fifteen orders of magnitude. Length dominates complexity. A random 16-character lowercase password (75.2 bits) is far stronger than a random 8-character password using every symbol on the keyboard (52.4 bits).
The rule most of us were trained on — one uppercase, one number, one symbol, changed every ninety days — is no longer the recommendation of the body that popularised it. The 2017 revision of the United States NIST digital identity guidelines removed mandatory composition rules and removed routine expiry, and advises checking new passwords against lists of known-breached ones instead.
The reasoning is behavioural. Forced rules do not produce random passwords; they produce predictable transformations of a memorable word. Capital at the front, digit and exclamation mark at the end, a becomes @, o becomes 0. Cracking tools have applied those exact substitution rules for two decades, so the entropy added is a fraction of what the rule appears to add. Forced ninety-day rotation makes it worse, because people increment a counter, and a leaked old password predicts the new one.
This also explains why browser strength meters mislead. Most score the string in front of them by counting character classes, but strength is a property of how the password was chosen, not how it looks. A meter cannot see that one password came from a cryptographic generator and another came from a birthday.
A word list of 7,776 entries — the Diceware size, five dice rolls per word — gives log2(7776) = 12.9 bits per word:
| Words | Entropy | Roughly equivalent to |
|---|---|---|
| 4 | 51.7 bits | 8 random ASCII characters |
| 6 | 77.5 bits | 12 random ASCII characters |
| 7 | 90.5 bits | 14 random ASCII characters |
So six random words are about as strong as twelve random symbols and enormously easier to remember, which makes a passphrase the right choice for the handful of passwords you must type from memory — your device login and your password manager itself. The critical condition is that the words be chosen randomly. A phrase you invented is not four words of entropy; it is one memory, and quoting a song lyric provides almost none.
This matters more than the character set. This generator draws from the browser cryptographic random source, crypto.getRandomValues, which is seeded by the operating system. The ordinary Math.random is unsuitable: it is fast and statistically fine for shuffling a list, but its internal state can be reconstructed from a short run of outputs, which means a sequence of generated passwords becomes predictable.
There is a second, subtler trap. Mapping a random byte (0–255) onto a 95-character alphabet with a remainder operation biases the first 66 characters upward, because 256 is not a multiple of 95. Correct implementations discard out-of-range values and draw again. The bias is small but it is a real reduction in entropy, and it costs nothing to avoid.
The entropy figures above assume the attacker knows your length and alphabet and is reduced to brute force. That is the correct conservative assumption; secrecy about your character set is not security.
More importantly, a strong password solves exactly one problem — guessing. It does nothing against phishing, where you hand it over willingly; nothing against a keylogger; nothing against a breach that exposes the password in usable form; and nothing against reuse. Reuse is the dominant real-world failure: credential-stuffing attacks replay one leaked pair across hundreds of sites, and a 130-bit password reused on a site that stored it carelessly protects nothing elsewhere. Uniqueness per site matters more than the strength of any single one, which in practice means a password manager, and phishing-resistant second factors or passkeys where they are offered.
Sixteen characters or more for anything stored in a password manager, since you never type it. For the few you must memorise, use a six or seven word random passphrase instead.
Usually legacy input filtering or a fixed database column, and occasionally the alarming sign that the password is being stored in a form where its length matters. A site with a low maximum length is worth treating as untrustworthy with anything you reuse.
No — change them when there is a reason: a breach notification, a shared device, or any suspicion of exposure. Scheduled rotation without cause reliably degrades password quality.
No. Generation happens entirely in your browser using its own random source, and nothing is transmitted, logged or stored. Nothing is kept after you close the page, so copy what you need before leaving.
Every tool comes with a written guide, and every category is one click away.