Password Generator

No. All generation happens locally using crypto.getRandomValues() in your browser. The password never leaves your device.

We use the Web Crypto API's CSPRNG (cryptographically secure pseudorandom number generator), seeded by your operating system's entropy source. This is the same API used by major password managers.

This tool generates strong passwords, but a password manager also stores, syncs, and auto-fills them. For day-to-day use, combine both: generate here, save in your manager.

Some sites limit special characters or password length. If a generated password is rejected, try disabling symbols or reducing the length. Most sites accept 12–20 characters with letters and numbers only — still very strong with our CSPRNG-based generator.

Modern guidance (NIST SP 800-63B) says change a password only when you suspect it's compromised — forced periodic changes just push people toward weaker, easier-to-remember passwords. But when you do rotate one, generate a fresh random password here instead of tweaking the old one.

Both are strong, but they solve different problems. A random string (what this tool generates) is ideal for API keys, tokens, and accounts you'll save in a password manager — maximum entropy per character. A passphrase (4–5 random words, think "correct horse battery staple") is better when you must memorize it with no manager, like a disk-encryption key or master password. The rule of thumb: if you can use a manager, go random; if you must type it often or memorize it, a passphrase wins on usability.

It estimates entropy in two dimensions: length and character-set variety. Length dominates — a 20-character lowercase-only password has roughly 95 bits of entropy, which is more than a 12-character password with all four charsets (~76 bits). The bar uses the same mental model as zxcvbn-style estimators: longer and more varied = exponentially more combinations for an attacker to brute-force.

Passkeys (WebAuthn) are replacing passwords on more sites every year, and that's a good thing: they're phishing-resistant and can't be leaked from a server breach. But you'll still need strong random passwords for a while — legacy sites without passkey support, API keys and tokens, and the master password of your password manager all still require one. Generate those here and let passkeys handle the rest.

Never reach for Math.random() or Python's random module — both are predictable and unfit for secrets. Use a CSPRNG instead. Python: secrets.token_urlsafe(20), or pick your own charset with secrets.choice(). Node: require('crypto').randomBytes(20).toString('base64url') — 20 bytes is 160 bits of entropy in 27 URL-safe characters. Go: crypto/rand with a rejection-sampled charset. CLI: openssl rand -base64 24 or tr -dc 'A-Za-z0-9!@#$%^&*' < /dev/urandom | head -c 24. This page uses the same class of generator in the browser via crypto.getRandomValues(), so its output is statistically equivalent — the difference is only that server-side generation never crosses a clipboard.

Treat it as public and rotate it immediately: generate a fresh random password here, save it in your password manager, and turn on two-factor authentication on that account. Check Have I Been Pwned to see which of your addresses are affected. Never "fix" a breached password by tweaking it (adding a number or a trailing !) — attackers and cracking tools try those mutations first.

Yes. Reuse is what turns one breached site into a dozen compromised accounts — credential stuffing takes the email/password pair from a dump and retries it against every major service within minutes. Generate a unique password per site and let your manager remember them. If you're not ready to migrate everything, at minimum keep email, banking, and cloud accounts on passwords you've never used anywhere else.

Only up to 72 bytes. bcrypt silently ignores everything past byte 72, so a 64-character password is already at the limit and any accented, CJK, or emoji character (2–4 bytes each in UTF-8) pushes it over. Two different long passwords sharing their first 72 bytes are the same password to the database, and the API never warns you. If you must keep bcrypt, pre-hash with SHA-256 and Base64-encode the digest before passing it in — Base64 rather than raw bytes, because a NUL byte in a raw digest would truncate it a second time. New projects should use Argon2id or scrypt, which have no length wall. For bcrypt-backed services, a 16–20 character generated password is the sweet spot: far past the truncation point and still easy to paste.

Because 256 is not a multiple of your alphabet size. With a 62-character alphabet, 256 ÷ 62 = 4 remainder 8, so the first eight characters can be produced by five byte values while the other 54 can be produced by four — those eight come up 25% more often. With a 10-character alphabet the remainder is 6, so the skew is worse. The output looks perfectly random to the eye, which is why the bug survives review. The fix is rejection sampling, not a different modulus: draw a byte, discard it if it is ≥ 248 (the largest multiple of 62 below 256), and redraw. crypto.randomInt() in Node, secrets.choice() in Python, and crypto/rand.Int in Go all do exactly this internally. This page uses crypto.getRandomValues() with the same rejection step.