Passphrase Generator

About this tool

Generate a memorable passphrase made of random, unrelated dictionary words — easier to type and remember than a random character string, while still being genuinely hard to guess. Uses crypto.getRandomValues for real randomness, never Math.random.

Where passphrase strength actually comes from. A password's real strength is measured in bits of entropy — roughly, log₂ of the number of equally likely outcomes an attacker would have to search through. This tool draws from an 80-word list, so each additional word multiplies the number of possible passphrases by 80: a 4-word passphrase has 80⁴ ≈ 41 million combinations (about 25 bits of entropy), while a 7-word passphrase has 80⁷ ≈ 2.1×10¹³ combinations (about 44 bits) — each extra word adds roughly log₂(80) ≈ 6.3 bits, which is why the word-count slider is the single biggest lever on strength here, far more than capitalization or an appended number.

Word count matters more than the extras. Capitalizing each word doesn't add meaningful entropy here (it's applied consistently, not per-word-randomly), and appending a random two-digit number adds under 7 bits (log₂(90) for the 10–99 range this tool uses) — useful mainly for satisfying a site's "must contain a digit" rule, not for real security. If you need a genuinely strong passphrase, favor more words over more decoration: 6+ words is a reasonable everyday target, matching the "Strong" and "Very strong" labels the strength readout shows.

Why words instead of random characters. A random string like xQ7$mK2!pL9# packs more entropy per character, but is genuinely hard to type accurately and nearly impossible to memorize. A sequence of unrelated real words — even nonsensical together — engages ordinary language memory instead of rote character memorization, and is far less error-prone to type on a phone keyboard, read aloud, or hand-copy. This is the same reasoning behind the well-known "correct horse battery staple" approach to passphrases.

Where a passphrase like this fits. Good for master passwords you type often (a password manager's own unlock phrase, a device's disk-encryption passphrase, a home network's Wi-Fi password) where memorability and error-free typing matter. For most individual website accounts, a password manager generating and storing a long random string per site remains the stronger overall approach, since you don't need to remember those at all.

To check an existing password's strength instead of generating a new one, use password strength checker; for a traditional random-character password, the password generator; for a random unique identifier rather than something human-memorable, the UUID generator.

Frequently asked questions

Why are word-based passphrases considered strong?

Strength comes from the total number of possible combinations, which grows multiplicatively with each added word — going from 4 to 6 words here roughly squares the number of possible passphrases, which matters far more for real security than any single added character.

Should I add a number or symbol?

It adds a little entropy and satisfies sites that require a digit, but word count matters far more for actual strength than a single appended number — prefer more words over relying on the digit.

Is this generated locally?

Yes — everything happens in your browser using the Web Crypto API's secure random number generator; nothing is sent anywhere or logged.

How many words should I actually use?

4 words is fine for a low-stakes or throwaway account; 6 or more is a reasonable target for something you care about, like a password manager's master passphrase or full-disk encryption.

How big is the word list, and does that matter?

80 words. A larger list would add slightly more entropy per word, but the word count matters far more overall — 7 words from an 80-word list beats 4 words from an even much larger list.

Why avoid Math.random() for this?

Math.random() isn't specified to be cryptographically secure and its output can, in principle, be predicted by an attacker in some implementations. crypto.getRandomValues draws from the operating system's secure randomness source instead, which is the appropriate choice for anything security-related.