Most accounts do not get broken into by someone defeating the encryption. They get broken into because the password was weak, reused, or easy to guess. Attackers run automated credential-stuffing and password-spraying campaigns against login portals, VPNs, and SSH hosts day and night, and they rarely need anything clever. They just need a password a human made up.
And humans are predictable. We capitalize the first letter, swap a for @ and o for 0, and tack a year or an exclamation mark on the end. Something like P@ssword2026! feels clever. To GPU cracking software trained on billions of leaked passwords, it is one of the first things checked. The fix is not to be cleverer than the cracker. It is to stop choosing passwords yourself and let a random generator do it.
That is what the Password Generator is for. It runs entirely in your browser, produces genuinely random credentials, and never sends them anywhere. Below is how it works and why the way it works matters.
Entropy, or how strength is actually measured
Password strength comes down to one idea: how many guesses an attacker needs before they are statistically likely to hit yours. That number is captured by entropy, measured in bits. Each bit doubles the number of possibilities, so a password with E bits of entropy takes up to 2^E guesses to brute-force.
The formula is simple:
E = L × log2(R)
L is the length in characters, and R is the size of the character pool you are drawing from. The pool depends on which character sets you include:
| Character set | Pool size (R) | Contents |
|---|---|---|
| Numeric only | 10 | 0-9 |
| Lowercase letters | 26 | a-z |
| Mixed-case alphanumeric | 62 | a-z, A-Z, 0-9 |
| Full ASCII symbol set | 94 | letters, digits, punctuation |
The pool size sets how much each individual character contributes. A full 94-character pool gives log2(94) ≈ 6.55 bits per character; lowercase-only gives log2(26) ≈ 4.70.
Why length wins
Here is the part people get backwards. Growing the character pool helps linearly. Growing the length helps exponentially. Compare two passwords:
- Password A — 8 characters, full 94-character pool:
E = 8 × log2(94) ≈ 52.4bits. That is94^8 ≈ 6.1 × 10^13combinations. A single GPU rig testing 100 billion guesses per second chews through that in minutes. - Password B — 20 characters, lowercase only:
E = 20 × log2(26) ≈ 94.0bits. That is26^20 ≈ 2.0 × 10^28combinations. The same rig would need billions of years.
Password B uses a smaller alphabet and no symbols at all, yet it is astronomically stronger, purely because it is longer. Stretch a full-pool password out and the effect compounds fast:
| Password | Approx. entropy | Time to crack at 100 billion/sec |
|---|---|---|
| 8 chars, full set | ~52.4 bits | ~10 minutes |
| 12 chars, full set | ~78.6 bits | ~150 years |
| 16 chars, full set | ~104.8 bits | ~11.7 billion years |
| 20 chars, full set | ~131 bits | effectively forever |
The practical takeaway: if you have to choose between adding a symbol and adding four more characters, add the characters. This is also why the generator's length slider (which runs from 8 to 64) is the most important control on it. Push it right.
Random is only as good as the randomness
Generating a password means picking characters at random, and not all randomness is equal. JavaScript's Math.random() is a pseudo-random number generator (PRNG). It is deterministic under the hood, built for speed rather than secrecy. Given the seed or enough observed output, an attacker can predict the values it produces next. That is fine for shuffling a playlist and disastrous for a password.
The Password Generator uses a cryptographically secure PRNG instead, through the browser's Web Crypto API and its crypto.getRandomValues() function. A CSPRNG seeds itself from real environmental entropy collected by the operating system, and it satisfies the "next-bit test": even if you have seen every bit it produced so far, you cannot predict the next one better than a coin flip. That unpredictability is the whole point.
Just as important, generation happens entirely on your machine. The characters are assembled client-side in your browser and are never transmitted across the network, so there is no server log, no request body, and no intermediary that could ever see a password you generate.
What the tool actually offers
The controls are deliberately plain:
- A length slider from 8 to 64. Longer is stronger; the math above is why.
- Toggles for uppercase, lowercase, numbers, and symbols, so you can match a site's requirements or your own preference.
- An "exclude ambiguous characters" option that drops lookalikes such as
I,l,1,O, and0. This makes a password easier to read off a screen or retype on a console or phone without meaningfully denting its entropy. - Bulk generation of up to 50 passwords at once, handy when you are provisioning a batch of accounts or service credentials.
Out of the box it defaults to a length of 8 with ambiguous characters excluded, so the first thing worth doing is dragging the length up. The tool reports strength as a category — weak, fair, strong, or very strong — rather than a raw bit count, which is a quick sanity check as you adjust the settings.
If you also need unique, collision-resistant identifiers for records, API keys, or database rows rather than human-facing passwords, the GUID/UUID Generator covers that neighbouring job.
What the guidelines now recommend
Modern credential advice, including NIST's SP 800-63B, lines up with the entropy math. Three points stand out. Favor length over forced complexity rules, and support long passphrases up to 64 characters or more. Drop mandatory periodic expiration; forcing a change every 30 or 90 days just pushes people toward Spring2026! then Summer2026!, so change a password when there is a reason to, not on a timer. And lean on a password manager such as Bitwarden, 1Password, or KeePass to store a unique, high-entropy credential for every service, since nobody can remember dozens of 20-character strings.
Put those together and the routine is short: generate a long random password here, store it in your manager, and never reuse it. That handles the overwhelming majority of the attacks that actually succeed.