All processing runs in your browser — no files or inputs are uploaded to a server.
Drag the length slider or type a number, toggle which character sets you want (lowercase, uppercase, digits, symbols), and a password regenerates automatically. The entropy bar shows roughly how hard the result is to brute-force, measured in bits: under 40 is weak, 60+ is good for most accounts, 90+ is strong enough for a vault master password.
The "no ambiguous" toggle drops glyphs that look alike across fonts — I, l, 1, O, 0, o, `, ', ", | — useful when the password might be typed off a screen or read aloud over the phone. Random bytes come from crypto.getRandomValues, and a reject-on-modulo-bias loop keeps each character equiprobable. Nothing leaves your browser.
length: 20 sets: lower + upper + digits + symbols pool: 87 chars
g7#Lq2!vWp9Bz@Yx5dKr ≈ 128.7 bits (very strong)
A safe default for any new account. 128 bits is far beyond what offline brute-force can crack within decades.
length: 16 sets: lower + upper + digits (no symbols) no ambiguous: yes pool: 52 chars
k7QxR2nbCa3VsT5p ≈ 91.2 bits (very strong)
Use when the password might be dictated on a call, typed on a phone, or entered into a system that mishandles symbols (some legacy SSO portals, certain databases).
length: 6 sets: digits only pool: 10 chars
482703 ≈ 19.9 bits (weak)
A 6-digit PIN is fine when the rate of guessing is limited (a bank card with 3 attempts, a phone screen lock). It is hopeless against any unrestricted attacker.
Length matters more than complexity once you cross about 12 characters. For online accounts protected by rate-limited logins, 16 with mixed sets is plenty. For a password manager master password or full-disk encryption, aim for 20 or more — those are vulnerable to offline brute force if the encrypted blob is stolen.
It uses crypto.getRandomValues, the cryptographically secure RNG browsers expose, seeded from the operating system's entropy source. That is the same generator backing TLS key generation in the browser — strong enough that the RNG is not the weakest link in any realistic threat model.
No. Generation happens in your browser; the result lives only in the page until you copy or refresh. We do not log it, sync it, or store it anywhere. Still, treat any password pasted into the clipboard as exposed — paste it straight into the destination field, don't leave it sitting in clipboard history.
Passphrases are excellent for passwords you have to type from memory — a vault master password, full-disk encryption. They are easier for humans to recall than random gibberish. For everything else stored in a password manager, a long random string is fine and uses fewer characters for the same entropy.
It estimates log2 of the number of possible passwords the same generator could have produced with the same settings. 60 bits means roughly 10^18 candidates. Each extra bit doubles that number. Real-world attack difficulty depends on how the password is stored — fast hashes (MD5, SHA-1) let attackers test billions per second, slow hashes (bcrypt, Argon2) tens per second on a single GPU.
Password strength comes from two independent factors: how long the string is, and how many characters could have appeared at each position. Multiply them in log space and you get entropy in bits — the log2 of how many candidates an attacker would have to try. A 12-character password drawn from a 70-character pool has about 73 bits of entropy; doubling to 24 characters doubles the bits to 146. Length is the cheapest knob, complexity the most overrated.
The rules NIST published in SP 800-63B in 2017 — and reaffirmed since — explicitly drop the old advice. Forced periodic changes, mandatory character-class mixes ("must contain one number and one symbol"), and security-question fallbacks are out. In their place: long minimum length, allow any printable characters, screen against breach corpora, rate-limit logins, and let the user choose how to remember it. The entropy of a freshly generated random password is good evidence the password manager you store it in is the actual control — losing access to the manager, not someone guessing the string, is the real failure mode to plan for.
Generate time-based one-time passwords (RFC 6238) compatible with Google Authenticator and 1Password. Paste a base32 secret or otpauth:// URL — codes update live, fully in-browser.
Compute HMAC signatures (SHA-1, SHA-256, SHA-384, SHA-512) for a key/message pair. Output as hex or base64, fully in-browser via Web Crypto.
Generate an RSA public / private key pair in PEM format (PKCS#1 or PKCS#8). Useful for JWT signing keys, SSH testing, and one-off encryption — for production keys, use OpenSSL.
Generate random UUIDs (v4) in your browser. Bulk generation up to 100 at a time.
Passwords are generated locally using crypto.getRandomValues — nothing is sent anywhere.