Random String, Passphrase, or Diceware? Picking a Password Your Future Self Can Actually Use

Published on May 18, 2026 by The Kestrel Tools Team • 9 min read

You open your password manager, click the little dice icon, and a 16-character mess of symbols appears in the box. You paste it into the signup form. The site’s strength meter goes red and tells you it’s “weak.” You stare at the screen. You ran the math in your head — a random 16-character password from a 94-character alphabet is roughly 105 bits of entropy, which is more than enough to outlast the heat death of every GPU farm on earth. The strength meter is wrong. But now you’re second-guessing yourself anyway, and the form is still empty.

This is the everyday reality of password generators in 2026. The tools work fine; the decision about what kind of output you want is the part nobody walks you through. A random string, a passphrase, and a Diceware-style word list are three different shapes of the same idea, and the right one depends on whether you’ll type it, read it aloud over the phone, store it in a vault, or paste it once and forget it forever.

This is the random password vs passphrase decision guide we wish existed: short, opinionated, with real entropy numbers and side-by-side example output. You can generate all three styles on Kestrel Tools’ Password Generator while you read — it runs entirely in your browser, so the passwords never leave your machine.

Random password vs passphrase: which one should you use?

Use a random string when a password manager is doing the typing for you, and a passphrase when a human has to type or remember it. Both can hit the same security level if you size them correctly — the difference is whether your fingers or your eyes are paying the cost. Diceware is a passphrase recipe with one extra property: the word list is public and standard, so the entropy calculation is auditable rather than hand-waved.

That one paragraph covers about 80% of real decisions. The rest of this post is the why, the example output, and the threat-model edges where it matters which one you pick.

What each style actually looks like

All three are built from the same crypto.getRandomValues() source we covered in Where Do Random Numbers Come From in Your Browser? — the randomness is identical; only the encoding changes.

Random string (16 chars, 94-char printable ASCII alphabet):

b#7Pq2!fLk9}vZ@1
4T^xR!8nJp%Hc&zQ
W3$mY7vL!9bN@xK2

Passphrase (4 random words, capitalized, no separator, with two random digits):

LanternMarrowVioletEcho47
CobaltThunderQuietBramble92
MeadowKnightOpalSparrow03

Diceware (6 words from the EFF long list, separated by hyphens):

broth-amplifier-juicy-flatfoot-recapture-tartness
spoiled-stoic-hardly-mongoose-stylus-trickle
zealous-overfull-sieve-corny-arsenic-flap

Notice they don’t look equally strong, but the entropy numbers tell a different story.

Password entropy bits: the only math that matters

Password strength reduces to one formula: entropy in bits = log₂(charsetⁿlₑⁿ₉ₜₕ). That’s it. The number tells you how many guesses an attacker would need on average to find your password, expressed in bits so you can compare across styles.

A short reference table for 2026:

Bits of entropy	Time to crack (offline, 10¹² guesses/sec)	Verdict
40 bits	About 18 minutes	Trivial — don’t bother
60 bits	About 13 days	Stops casual attackers, fails determined ones
80 bits	About 38,000 years	Safe against today’s offline attacks
100 bits	About 4 × 10¹⁰ years	Comfortable margin for the next decade
128 bits	Heat death of the universe territory	Overkill but symmetric with AES-128

The 10¹² guesses/sec number is a high-end offline cracking rig as of 2025 — single high-end consumer GPUs hit roughly 10¹⁰–10¹¹ guesses/sec on a fast hash like NTLM, and a small cluster pushes that into the 10¹² range. For slow hashes (bcrypt, Argon2), drop the rate by a factor of 10⁴ to 10⁶ — which is exactly why the modern guidance is “pick a slow hash and a long password,” not one or the other.

Now the styles:

• Random string, 16 chars, 94-char alphabet: log₂(94¹⁶) ≈ 105 bits. Plenty.
• Passphrase, 4 random words from a 10,000-word list, plus two digits: log₂(10000⁴ × 100) ≈ 60 bits. Below the modern threshold.
• Passphrase, 5 random words from a 10,000-word list: log₂(10000⁵) ≈ 66 bits. Still light.
• Diceware, 6 words from the 7,776-word EFF long list: log₂(7776⁶) ≈ 77 bits. Right at the edge.
• Diceware, 7 words: log₂(7776⁷) ≈ 90 bits. Strong.
• Diceware, 8 words: log₂(7776⁸) ≈ 103 bits. Matches the random 16-char string.

The takeaway: a 4-word passphrase is not equivalent to a 16-character random password, no matter how often the XKCD comic makes the rounds. To match the entropy of a 16-char random string, you need 8 Diceware words or about 11 of those friendly camelCase passphrase words. Which is fine — they’re still easier to type than b#7Pq2!fLk9}vZ@1 — but you have to size up.

When a random string is the right answer

Reach for a random string when:

• A password manager will autofill it. You’ll never type it. Length is free; legibility is irrelevant.
• It’s stored in a config file or secret manager. Same logic — a CI runner doesn’t care that b#7Pq2!fLk9}vZ@1 is ugly.
• You need maximum entropy per character. Tight character limits (some legacy systems cap passwords at 16 or 20 chars) make every bit count, and 6.55 bits/char from a 94-char alphabet beats 12.9 bits/word divided by ~6 chars/word from a 10,000-word list.
• The site’s password rules require symbols. Most passphrase generators will fight you on this; a random-string generator will just include them.

A practical rule: if the password lives only in your password manager and gets pasted by software, generate a random 16-character (105-bit) string and move on. Anything longer is theater; anything shorter is cutting it close.

When a passphrase or Diceware is the right answer

Reach for a passphrase when something between you and the bytes is human:

• Your password manager’s master password. You’ll type it dozens of times a day, on phones, on laptops, in airports. Typing correct-horse-battery-staple-ridge-anchor-glacier-stone is realistic. Typing b#7Pq2!fLk9}vZ@1Q&8x*K3wM!2nL ten times before coffee is not.
• Your full-disk encryption (FDE) password. Same reasoning. Plus FDE passwords are typed before the OS loads, which means your password manager isn’t there to help.
• An SSH key passphrase. Long, typed occasionally, needs to be memorable enough to survive a six-month gap between uses.
• A recovery phrase you might read aloud over the phone to support. “Capital lima alpha november…” is faster than spelling out symbols.
• A hardware-token unlock PIN where the device caps PIN length but accepts arbitrary characters. Small character set, short length — reach for what’s most memorable per character of typing effort.

Diceware is the version of “passphrase” you should pick when the entropy claim has to be defensible. The EFF long list is public, the word count is public, the math is reproducible by anyone reviewing your threat model. Hand-rolled passphrase generators (“random words from some dictionary”) often quietly draw from a list of 1,000 or 2,000 common English words instead of 7,776+, which silently strips 5–10 bits per word. If you’re documenting a security control or writing a runbook, Diceware lets you write “6 words × 12.92 bits/word = 77.5 bits of entropy” and have a reviewer agree.

Decision matrix: random vs passphrase vs Diceware

Use case	Random string	Passphrase	Diceware
Password-manager-stored web logins	Recommended (16+ chars)	Overkill on length	Overkill on length
Password manager master password	Painful to type	Recommended (5–6 words)	Recommended (6–7 words)
Full-disk encryption password	Painful to type	Recommended	Recommended
SSH key passphrase	Fine if pasted from manager	Recommended	Recommended
API key / token in env file	Recommended (or use a generated secret)	Avoid — wastes length	Avoid
Service account in CI	Recommended	Avoid	Avoid
Recovery phrase read aloud	Avoid — ambiguous chars	OK	Recommended — unambiguous wordlist
Documented control with audit	OK	Hard to defend math	Recommended — reproducible entropy
One-time temp password emailed to a user	Recommended	Acceptable	Acceptable

If the row says “Recommended” in only one column, that’s almost always the right pick.

How long is long enough in 2026?

A practical floor for new passwords this year:

• Random string: 16 characters from a 94-char alphabet → ~105 bits. Don’t go shorter.
• Passphrase from a 10,000-word generator list: 7 words → ~93 bits. Add a digit or two if you want a round 100.
• Diceware (EFF long list): 7 words → ~90 bits. 6 words is the absolute floor (~77 bits) — viable for routine accounts behind a slow hash, weak for anything an attacker can grind offline.

These floors assume the password is the only thing protecting the account. If MFA, hardware keys, or a properly configured Argon2 hash sits in front, the practical security is much higher than the entropy number alone suggests — but plan for the day the database leaks, because that’s the day entropy is the only thing left.

Note what these numbers don’t include: any predictable structure. “Summer2026!” has roughly the entropy of a 12-character random string on paper and roughly zero in practice, because it matches the patterns every cracking dictionary tries first. Random means random.

Common pitfalls

A few mistakes that show up in code review and password audits:

• Counting character classes as a strength signal. “Has uppercase, lowercase, digits, and symbols” is a UX hack from 2003 that has nothing to do with entropy. A 4-class 8-char password is weaker than a 12-char lowercase-only one.
• Using Math.random() to generate the password. Don’t. Anything pretending to be random for a security purpose has to come from crypto.getRandomValues() or your platform’s CSPRNG. We covered the full reasoning in Where Do Random Numbers Come From in Your Browser?.
• Modulo bias when mapping bytes to alphabets. If your alphabet length doesn’t divide 256 evenly, naive byte % length skews the distribution. Use rejection sampling. Most browser password generators (including ours) handle this for you, but a hand-rolled Math.floor(Math.random() * alphabet.length) does not.
• Hand-picking words for a passphrase. “My favorite 4 words” has roughly 10–20 bits of entropy because attackers know which words humans pick. Random selection from a fixed list is the entire point of Diceware.
• Generating passphrases on a server you don’t control. The whole reason a client-side password generator exists is so the password never lands in someone else’s logs. If you’re typing the master password into a website that POSTs it back to a server before showing it to you, the math doesn’t matter — you’ve already compromised it.
• Hitting the site’s max-length cap and silently truncating. Test the round-trip. Some sites accept any password at signup, then truncate to 32 characters at login.

What this post deliberately doesn’t cover

To keep the scope tight, this guide only covers the shape of a generated password. Adjacent topics worth their own posts:

• Rotation policies (modern guidance: rotate on compromise, not on a schedule).
• Multi-factor authentication and hardware keys.
• Password manager threat models and selection.
• Server-side password storage (Argon2, bcrypt, scrypt).
• Recovery flows and account-recovery passphrases.

Those all interact with password choice, but a 9-minute read can’t carry them all without flattening the actual decision.

So which one should you use?

Reach for a random 16-character string by default, generated client-side and stored in a password manager. Switch to a 5–7 word passphrase or 6–8 word Diceware list for the small set of passwords a human actually has to type — vault master, FDE, SSH key. Size up to match 100+ bits of entropy whenever the password protects anything an attacker would care about cracking offline.

If you want to feel the difference, generate one of each and try retyping them from memory after lunch. The ranking will be obvious within five seconds.

You can try this in the browser right now with the Kestrel Tools Password Generator — it produces random strings, passphrases, and Diceware-style lists side by side, with a live entropy estimate for each, all client-side. Open dev tools, watch the empty Network panel, and you’ll see what “client-side” actually means: the bytes start in the OS, end in your clipboard, and never touch a server in between.

That’s the entire question. Pick the shape that matches who’s typing it, then size it for 100 bits of entropy or more, and stop trusting the strength meter.