How long should a password be in 2026?

At least 12 characters, 16+ recommended. For master passwords of a password manager or disk encryption, 6 random Diceware words (~77 bits) or 20 random characters is the right ballpark. NIST SP 800-63B-Rev4 puts 8 as absolute floor, but that is only the compliance minimum, not the security target.

Is Math.random() safe enough for passwords?

No. Math.random() is a deterministic PRNG (xorshift128+ in V8/Chromium) and not designed for security — internal state is only 128 bits and predictable. This generator exclusively uses crypto.getRandomValues() , which is wired to the OS cryptographic source (CSPRNG).

Are my passwords stored or transmitted anywhere?

No. Generation runs entirely in your browser. No network requests, no logs, no analytics see the generated password. You can verify this in DevTools (Network tab) — nothing is sent on generate.

Should I use a unique password per account?

Yes, absolutely. If service A logs the password in plaintext or gets hacked (see haveibeenpwned.com with 13+ billion leaked credentials as of 2026), service B must not fall with the same password. Password managers exist precisely for this: remember only the master password, everything else is randomly generated and auto-filled.

Passphrase or character password — which is better?

Both reach the same security level if entropy matches. Passphrases are better when you have to type or read from a phone screen (master passwords, SSH key passphrases, wallet seeds). Character passwords are better for anything the password manager auto-fills — they are shorter and have fewer bytes for any input-length limit.

What does "exclude similar characters" mean?

The option removes visually confusable characters: 0 vs. O , 1 vs. l vs. I . Useful when the password is typed from a printout or screen (server maintenance, printer setup). Trade-off: slightly reduced entropy per character — at 16 chars it costs about 0.3 bits, negligible.

Password Generator

Strong passwords or memorable passphrases — cryptographically random in your browser.

{{ __t('entropy') }}: {{ strength.bits }} bits

{{ __t('opt_length') }}{{ length }}

{{ __t('opt_lower') }} (a-z)

{{ __t('opt_upper') }} (A-Z)

{{ __t('opt_digits') }} (0-9)

{{ __t('opt_symbols') }} (!@#$…)

{{ __t('opt_excl_similar') }} (0Ol1I)

{{ __t('opt_excl_ambig') }} ({}[]…)

{{ __t('opt_words') }}: {{ words }}

What makes a good password?

A strong password resists both brute-force and dictionary attacks. Four core principles:

Long — at least 12, ideally 16+ characters. Every extra character multiplies the work for attackers.
Mixed — combine upper-/lowercase letters, digits and symbols
Unique — every account needs its own password. One leak must not endanger all your accounts.
Random — no birthdays, names, or dictionary words. True randomness (via `crypto.getRandomValues`) is essential.

Passphrases vs. passwords

A passphrase of 4–6 random words (the Diceware method) offers security comparable to a random character password but is far easier to remember and type. For master passwords (password managers, disk encryption), passphrases are often the better choice.

Is this generator secure?

Yes. Random numbers come from `crypto.getRandomValues()` directly in your browser — a cryptographically secure source. There is no server round-trip, no log, no tracking. You can inspect the implementation in your browser's developer tools at any time.

Understanding entropy: why 12 characters are not always 12 characters

The entropy of a password measures how unpredictable it is — in bits. A password with 60 bits of entropy means an attacker needs on average 2^59 (about 576 quadrillion) guesses to crack it. What matters is not length alone but the size of the alphabet each character is drawn from uniformly at random. This generator uses crypto.getRandomValues() — a cryptographically secure source the browser pulls from the OS pool (e.g. /dev/urandom on Linux).

A password like Dog2024! looks strong with 9 characters and 4 character classes, but is actually a dictionary variation crackable in seconds. NIST SP 800-63B (USA) abandoned forced complexity rules in 2017 and now recommends long, freely chosen passwords (8 minimum, 15+ ideal) plus checking against breach lists (e.g. haveibeenpwned.com).

Rule of thumb: Diceware passphrases of 6 words from a 7776-word list deliver about 77 bits of entropy — enough to occupy even dedicated hardware (e.g. an RTX 4090 at ~200 GH/s against unsalted SHA-1) for more than 10^14 years. For master passwords of a password manager, 6 or 7 words is the gold standard. For throwaway accounts (stored in the manager), 16 random characters from a 94-character alphabet (~105 bits) is plenty.

The entropy formula

For a random password of length L drawn from an alphabet of N characters, the entropy H in bits is:

H = L * log2(N)

Examples:
- 8 chars, lowercase only  (N=26):     8 * 4.70 =  37.6 bits
- 12 chars, alphanumeric   (N=62):    12 * 5.95 =  71.5 bits
- 16 chars, full alphabet  (N=94):    16 * 6.55 = 104.9 bits
- 4 Diceware words         (N=7776):   4 * 12.92 = 51.7 bits
- 6 Diceware words         (N=7776):   6 * 12.92 = 77.5 bits

Realistic crack times

Assume an attacker has the salted bcrypt hash (cost=12, roughly 250 ms per attempt on a modern GPU). That gives them about 10,000 attempts per second per GPU. What does that mean in practice?

8 chars, lowercase only (e.g. password-style): 26^8 = 2.1 * 10^11 combinations. Exhaustive search: ~240 days on one GPU, a few hours on a 100-GPU rig. Not enough.
12 chars, alphanumeric (e.g. K3p9XaT2qLm8): 62^12 = 3.2 * 10^21 combinations. Exhaustive search: ~10^10 years on one GPU. Even a 10,000-GPU rig needs over a million years. Practically safe.
16 chars, full alphabet (e.g. r5$Lm!9pQ#xK7zF2): 94^16 ≈ 3.7 * 10^31. Even with the entire Bitcoin mining hashrate (≈ 6 * 10^20 H/s as of 2025) against an unsalted hash: ~2 * 10^3 years. Against bcrypt: astronomical. More than enough.
4 Diceware words (e.g. correct-horse-battery-staple, the famous XKCD-936 example): 7776^4 = 3.7 * 10^15 combinations. Against bcrypt: ~10^4 years. Solid for most accounts, marginal for high-stakes master passwords.
6 Diceware words (e.g. anchor-moon-spring-mirror-copper-dew): 7776^6 = 2.2 * 10^23 combinations. Recommended size for KeePass, 1Password or Bitwarden master passwords. Even at a hypothetical 10^15 attempts per second, 7 billion years are not enough. Gold standard.

Limits and realistic threat models

Even the strongest password does not help against phishing, keyloggers, cross-site reuse or server-side plaintext storage. Highest-impact-per-effort moves: (1) use a password manager so every account gets its own 16+ char password; (2) FIDO2/WebAuthn hardware keys (e.g. YubiKey) instead of SMS 2FA; (3) for the master password, use a 6-word passphrase with one capital and one symbol. Also: a random 8-character password is still crackable against unsalted MD5 or SHA-1 hashes (legacy systems) — the storage scheme (bcrypt, scrypt, Argon2id) is part of the security budget. See the OWASP Password Storage Cheat Sheet.

Frequently asked questions

How long should a password be in 2026?: At least 12 characters, 16+ recommended. For master passwords of a password manager or disk encryption, 6 random Diceware words (~77 bits) or 20 random characters is the right ballpark. NIST SP 800-63B-Rev4 puts 8 as absolute floor, but that is only the compliance minimum, not the security target.
Is Math.random() safe enough for passwords?: No. Math.random() is a deterministic PRNG (xorshift128+ in V8/Chromium) and not designed for security — internal state is only 128 bits and predictable. This generator exclusively uses crypto.getRandomValues(), which is wired to the OS cryptographic source (CSPRNG).
Are my passwords stored or transmitted anywhere?: No. Generation runs entirely in your browser. No network requests, no logs, no analytics see the generated password. You can verify this in DevTools (Network tab) — nothing is sent on generate.
Should I use a unique password per account?: Yes, absolutely. If service A logs the password in plaintext or gets hacked (see haveibeenpwned.com with 13+ billion leaked credentials as of 2026), service B must not fall with the same password. Password managers exist precisely for this: remember only the master password, everything else is randomly generated and auto-filled.
Passphrase or character password — which is better?: Both reach the same security level if entropy matches. Passphrases are better when you have to type or read from a phone screen (master passwords, SSH key passphrases, wallet seeds). Character passwords are better for anything the password manager auto-fills — they are shorter and have fewer bytes for any input-length limit.
What does "exclude similar characters" mean?: The option removes visually confusable characters: 0 vs. O, 1 vs. l vs. I. Useful when the password is typed from a printout or screen (server maintenance, printer setup). Trade-off: slightly reduced entropy per character — at 16 chars it costs about 0.3 bits, negligible.