Password generate.

Random isn't random — it has to be unpredictable.

Math.random() in JavaScript is a deterministic pseudorandom function seeded from a non-cryptographic source. Given a few observed outputs, an attacker can model the internal state and predict every subsequent value. The same is true of java.util.Random, Python's random module, and the C library's rand(). None of them are appropriate for generating passwords, tokens, session IDs, or any secret value.

The correct primitive is a cryptographically secure pseudorandom number generator — a CSPRNG — which is seeded from the operating system's entropy pool (kernel-collected timing jitter, hardware noise, RDRAND on x86) and produces output that is computationally indistinguishable from true randomness. In the browser, this is crypto.getRandomValues() and crypto.randomUUID(). In Node, crypto.randomBytes() and the same webcrypto APIs. In Python, the secrets module. In Go, crypto/rand. In Java, java.security.SecureRandom.

This generator uses crypto.getRandomValues() exclusively. Every byte of every password produced here is sourced from the browser's CSPRNG, which on modern systems is seeded from a kernel-level entropy source (Linux /dev/urandom, Windows CryptGenRandom, macOS getentropy). The output cannot be predicted by an attacker who observes other passwords from the same generator.

Length × alphabet, in bits.

Password strength is conventionally measured in bits of entropy, where one bit corresponds to a doubling of the search space. A truly random binary string of n bits has n bits of entropy by construction. For a password of length n drawn from an alphabet of a distinct characters with each position chosen independently and uniformly, entropy is n · log₂(a). That formula collapses cleanly: a 12-character all-lowercase password has 12 × log₂(26) ≈ 56 bits; raise the alphabet to mixed case + digits (62 chars) and 12 characters give 71 bits; add symbols (~95 printable ASCII chars) and 12 characters give 79 bits.

Length matters more than alphabet size. Doubling the alphabet adds one bit per character; doubling the length doubles the entropy. A 20-character random password from a 62-char alphabet (119 bits) is dramatically stronger than a 12-character password from a 95-char alphabet (79 bits), and easier to generate. This is why modern guidance from NIST SP 800-63B (revised 2020) deprecated forced complexity rules in favour of length minimums and rejection of breached passwords.

The crack-time estimate above the controls is a back-of-envelope calculation against an attacker running 10¹¹ hash attempts per second. That figure is roughly what a single high-end consumer GPU can do against MD5; against bcrypt with reasonable cost factor, a similar GPU drops to a few thousand attempts per second, multiplying the crack time by about 10⁸. The "crack time" reported here is the worst-case for a fast hash. If you know the target system uses a modern slow hash (bcrypt, scrypt, argon2id), divide by the relevant slowdown factor.

Words you can remember.

Arnold Reinhold's Diceware (1995) proposed using physical dice to select words from a numbered list, producing memorable passphrases with calculable entropy. Five rolls of five dice select one word from a 7,776-word list (6⁵ = 7776), so each word contributes log₂(7776) ≈ 12.92 bits of entropy. A six-word passphrase has ≈ 77 bits — comfortably above NIST AAL2.

The Electronic Frontier Foundation's 2016 large list refined Diceware's vocabulary: words 3–9 letters long, no homophones, no offensive terms, distinct first three letters where possible. The result is more memorable and easier to type than the original. Bitwarden, 1Password, Proton Pass, and most modern password managers offer EFF-style passphrase generation as a first-class option. The passphrase mode in this tool draws from an abridged version of the EFF list; the full 7,776-word list increases entropy slightly per word but isn't necessary for everyday use.

The argument for passphrases over random strings is human memory. A 5-word passphrase with separators can be retyped from memory; a 12-character random string usually cannot. For master passwords (the one secret you must memorise) and for shared team secrets that get spoken aloud, passphrases win. For everything else — site-specific account passwords, API keys, recovery codes — let a password manager generate per-site random strings and forget them.

A strong password is half the answer.

A password's resistance to attack depends as much on how the verifier stores its hash as on the password itself. Modern guidance: store passwords with a memory-hard, time-tunable function — argon2id (winner of the 2015 Password Hashing Competition, OWASP top recommendation), or scrypt or bcrypt as fallbacks — never with plain SHA-256, MD5, or single-iteration PBKDF2. Salt every entry with a per-user random nonce so identical passwords don't share a hash. Tune the cost parameter so authentication takes 100–500 ms on production hardware; this slows online attackers but stays imperceptible to legitimate users.

If your password ends up in a breach (Have I Been Pwned now indexes more than 12 billion compromised credentials), even a strong password becomes weak — attackers test breached passwords first. Best practice: rotate any password that appears in a breach, and use the k-anonymity API at api.pwnedpasswords.com/range/{first 5 hex chars} to check candidate passwords without sending the full hash.

Most account breaches in 2024–2025 trace back to credential reuse — a password leaked from one site is replayed against others (credential stuffing). The single most effective defence at the user level is generating unique, random per-site passwords with a manager. The strength of any individual password matters far less than not reusing it.

The post-password stack.

Passwords are a backstop, not a strategy. Modern authentication stacks layer multiple factors: something you know (password), something you have (TOTP device, security key, push-approved phone), something you are (biometric). Even if a password is compromised, second-factor verification denies the attacker access. NIST AAL2 and AAL3 both require at least two factors; consumer services have largely adopted at least optional 2FA.

The next step is passwordless. WebAuthn / passkeys (FIDO2) replace passwords with a public-private keypair stored on the user's device. The private key never leaves; the server stores the public key; authentication is a challenge-response signed by the device. Apple, Google, and Microsoft have all rolled out passkey support across their consumer products in 2023–2024. For new applications, treat passkeys as the primary path and passwords as the fallback — not the other way around.

Hardware security keys — YubiKey, Titan, Solokey — are the highest-assurance option for human users. Phishing-resistant by construction (the key signs only against the legitimate origin), unlinkable across sites, immune to credential-stuffing. The friction is real (keys cost real money, must be carried, can be lost) but the security gain is dramatic for high-value accounts: privileged systems administrators, journalists in hostile environments, executives with phishing-target email.

Sixty years of getting it wrong.

The first stored passwords were Compatible Time-Sharing System (CTSS) at MIT, 1961, in a plaintext file. The first major password leak — Allan Scherr's printout of every CTSS user's password to extend his time allocation — was in 1962. The first hashed passwords were UNIX in 1973 (Robert Morris and Ken Thompson), using a modified DES; this lasted until the late 1990s when DES brute force became commodity and crypt was replaced by MD5-based and then bcrypt-based schemes.

The 2000s introduced password complexity rules (uppercase + lowercase + digit + symbol) on the theory that they raised the search space. Empirically they did the opposite — users responded with predictable patterns (Password1!, Summer2023!) that attackers learned to enumerate. NIST SP 800-63B in 2017 deprecated complexity requirements and forced rotation in favour of length minimums and breach-list rejection. Most major identity providers — Google, Microsoft, Apple — adopted the new guidance within three years.

The 2010s normalised password managers. 1Password (2006), LastPass (2008), Bitwarden (2016), and KeePass family tools made per-site randoms practical for ordinary users. The 2020s normalised passkeys and platform-level passwordless, with Apple iCloud Keychain, Google Password Manager, and Windows Hello all syncing FIDO2 credentials across devices. The trajectory points away from human-typed secrets toward device-bound asymmetric crypto. The password generator on this page is a transitional tool — useful while passwords still exist, less critical once they don't.

What attackers actually run.

Online brute force is the textbook attack but rarely the practical one. Modern services rate-limit failed attempts (often 5 per minute per account, with progressive lockout); 10⁶ attempts per second is impossible. Online brute force only works against systems with no rate limiting or against accounts where the attacker controls many source IPs (botnets).

Offline brute force is the danger. After a database breach, the attacker has the hashes and can throw arbitrary CPU/GPU/ASIC at them. Modern GPU rigs do 10¹¹ MD5 hashes per second; specialised ASICs reach 10¹⁴. This is why hash function choice matters as much as password strength: a strong password protected by a fast hash is still recoverable; a weak password protected by argon2id is not.

Credential stuffing is the most common attack in practice. Attackers harvest leaked credentials from one breach and replay them against other services. The cost per attempt is near-zero (the attacker already has the password); the success rate per pair is roughly 0.5–2% on consumer services. Defence is unique passwords per site (kills stuffing entirely) plus 2FA on accounts where reuse can't be enforced.

Phishing bypasses password strength entirely. The attacker tricks the user into entering credentials on a lookalike site. Strong passwords don't help; 2FA helps somewhat (push-approved is phishable, TOTP is partially phishable, hardware keys are not phishable by construction). Phishing-resistant authentication is the only complete defence.

Targeted attacks — keyloggers, malware, shoulder-surfing — bypass everything if the attacker controls the user's device. The defence stack pivots from authentication to endpoint protection: full disk encryption, biometric unlock, application sandboxing, principle of least privilege.

How to use this tool well.

For a per-site account password, generate a 16+ character random string with all four classes enabled and store it in a password manager. You will never type it; the manager will. The "avoid look-alikes" toggle is irrelevant here because the manager copies and pastes verbatim.

For a master password (the one secret that unlocks the manager), generate a 6–8 word EFF passphrase with capitalisation and a 4-digit suffix. This is the password you will type by hand on a regular cadence; memorability matters, and at 80+ bits of entropy it is comfortably stronger than typical password requirements.

For a numeric PIN (device unlock, SIM, banking), 6 digits is the contemporary minimum and gives 20 bits of entropy — which is intentionally weak, because the verifier rate-limits aggressively (3 attempts then lockout, no offline brute force possible). PIN length matters less than the lockout policy of the device.

For API keys, OAuth secrets, signing keys, and other machine-to-machine credentials, do not generate from this tool. Use the platform's documented method (AWS IAM, Google service accounts, GitHub fine-grained PATs) which produces keys of the correct format and registers them with the right ACL. The secrets generated here are not interchangeable with platform secrets even if the entropy looks similar.

For shared team secrets — staging-environment database password, CI/CD signing key — use a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Doppler) with audit logging. Generation matters less than rotation discipline and access control. Rotate aggressively after any team member leaves.