Diceware Passphrase Generator

About the Diceware Passphrase Generator

Why is Diceware considered more secure than a random character password?

Per character, a random ASCII password is denser - a 12-character mixed-case alphanumeric password has about 71 bits of entropy. The catch is that humans cannot reliably memorise random ASCII strings, so in practice they either pick weak patterns or store the password somewhere it can be stolen. A 6-word Diceware passphrase contains roughly 77 bits of entropy (more than the random 12-character password), but the words are real, pronounceable English drawn from a common list, so they pass through the human visual-auditory memory loop in seconds. The tradeoff is length on screen versus memorability in your head - and for master passwords, memorability wins because a passphrase you can recall is a passphrase you do not have to write down.

How many words should I use?

For most online accounts protected by rate-limited login pages, six EFF words (~77 bits) are overkill - the attacker is bottlenecked at hundreds of guesses per second, so even 50 bits takes geological time. For password manager master passwords, encrypted disk volumes, and offline secrets that an attacker could brute-force on GPUs at 10 billion guesses per second, the recommendation jumps to seven (~90 bits) or eight (~103 bits) words. Bitcoin's BIP-39 seed phrases use 12 words from a much larger 2048-word list, which works out to 132 bits - the gold standard for cryptocurrency keys. Use the entropy meter on this page as your guide: aim for at least 80 bits, and over 100 bits for anything irreversible.

Is JavaScript's randomness actually safe for this?

Yes - this tool uses crypto.getRandomValues, which the W3C Web Crypto API defines as a cryptographically secure pseudo-random number generator (CSPRNG). All major browsers implement it on top of the operating system's entropy pool (getrandom on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS), and it is the same primitive used by HTTPS, WebAuthn, and password managers. The older Math.random function is not safe and is never used here. Additionally, the tool applies rejection sampling when reducing a 32-bit random integer to the 0-7775 range, which eliminates the small but non-zero modulo bias that a naive 'random % 7776' would introduce.

Does the generated passphrase or wordlist get sent to a server?

No. The 7776-word EFF list is downloaded once as a static JSON file (and cached forever by your browser), and from that point on, all dice rolling, word lookup, and assembly happens in the browser tab. There is no API call, no logging, and no analytics on the passphrase output. You can verify this by opening the Network tab in DevTools before clicking Generate: only the initial wordlist fetch should appear. This makes the tool safe to use for actual production passwords, recovery seeds, and vault keys, including on shared or air-gapped machines (after the first load you can even use it fully offline).

Why does capitalising every word add zero entropy?

Entropy measures the attacker's uncertainty about your choice. If the attacker knows your generation rule, and the rule is 'always capitalise the first letter of every word', then every guess they make already incorporates that capitalisation. There is no extra randomness for them to overcome, so the entropy gain is zero. Capitalising letters at random positions inside words would add entropy - but it would also make the passphrase nearly impossible to remember, defeating the purpose of Diceware. The trailing random digit and trailing random symbol, by contrast, add real entropy because the position and value are both unknown to the attacker.

Can I roll real dice and get the same result?

Yes - that is exactly why Diceware was invented. Turn on 'Show 5d6 dice rolls', generate a passphrase, and you will see five-digit blocks like 23541 next to each word. To reproduce the passphrase on physical dice, roll five distinct dice (or one die five times), write down the five digits in order, and look up that entry in the EFF wordlist (downloadable as a PDF from eff.org). For truly high-value secrets - a cryptocurrency hardware-wallet seed, an offline backup encryption key - rolling real dice removes any remaining uncertainty about CSPRNG quality or browser compromise, at the cost of a few minutes of dice-rolling per word. Because the dice rolls are reproducible on an air-gapped machine, you can verify the exact same passphrase offline without trusting any browser or server.

Is a Diceware passphrase NIST SP 800-63B and OWASP compliant?

Yes, and easily. NIST SP 800-63B treats memorized secrets primarily by length: it requires verifiers to allow at least 8 characters (and recommends supporting 64+), forbids composition rules and forced rotation, and tells you to screen against breached-password lists - all of which a Diceware passphrase passes trivially, since a 6-word EFF phrase is 20+ characters of words that never appear in breach corpora. NIST does not mandate a fixed bit count for user-chosen secrets, but its analysis equates a strong memorized secret with high guessing-resistance; ~60 bits is a common floor for rate-limited online use and is the lowest preset here. OWASP's Authentication and Password Storage guidance recommends long, high-entropy passphrases and a practical minimum around 80 bits for important accounts - which is the 'OWASP strong' preset. Use the Security-goal selector to lock in a documented target: pick NIST online (60), OWASP strong (80), Vault (100), or Paranoid (128), and the tool auto-sizes the word count and shows a PASS/FAIL badge you can screenshot for an audit trail. For a password-manager workflow, generate here, paste the passphrase into the master-password field of KeePass, Bitwarden, or 1Password (or a 7-Zip/VeraCrypt archive key), and let the manager store every other credential - you only ever memorize this one high-entropy phrase.