Password Generator or Passphrase? How I Choose in 2026
13 June, 2026 Security
I keep two generators pinned in my browser, and which one I open is a decision I now make in about a second. Random string or passphrase? For years I treated that as a style preference — some people like kQ7$mPx2!n3Rv8wL, some like chimp-gravel-parka-unbolted. That framing is wrong. The choice is not about taste, it is about who or what has to type the secret, and how often. Get that one question right and the rest follows. Get it wrong and you end up retyping a 24-character symbol soup on your phone six times a day, or memorising a passphrase for a credential no human will ever read.
This is the decision article I wish I had when I started. It does not re-derive the entropy maths — I covered that in the password entropy guide — and it does not relitigate why words beat keyboard noise for memorised secrets, which is the whole point of the diceware passphrase guide. This piece is the layer above both: given a specific secret in front of you, which generator do you reach for, and why.
The One Question That Decides It
Will a human type this secret from memory, or will only a machine ever handle it?
That is the whole decision tree. Everything else is a refinement.
- Human-typed from memory → passphrase. The passphrase generator exists for exactly this. Words you can recall, type on a phone, and read aloud over a phone call without spelling out punctuation.
- Machine-handled, stored, never memorised → random string. The random password generator gives you maximum entropy per character, and the character count costs you nothing because you never type it.
The mistake almost everyone makes is optimising the wrong half. They generate a gorgeous 32-character random API key and feel secure — fine, that is correct. Then they use the same generator for their password manager master key and spend the next year fighting it. Or they go the other way: a memorable passphrase for a database password that lives in a secrets manager and is never seen by human eyes, throwing away entropy density for a memorability nobody will ever use.
The Use-Case Matrix
Here is how I actually map secrets to generators. The "why" column is the part worth internalising — once the reasoning clicks you stop needing the table.
| Secret | Reach for | Why |
|---|---|---|
| Password manager master key | Passphrase (7-8 words) | Typed daily from memory, cannot be stored anywhere else |
| Full-disk encryption / recovery key | Passphrase | Typed at boot, often under stress, sometimes transcribed |
| SSH / GPG key passphrase | Passphrase | Re-entered occasionally across machines, memorised |
| Per-site account password | Random string (20+ chars) | Manager types it; you never see it |
| API keys, DB credentials, service tokens | Random string (32+ chars) | Pure machine-to-machine, copied from a vault |
| CSRF / session tokens | CSPRNG binary, not either tool | Programmatic, never displayed |
| A WiFi password guests will type | Passphrase (short, 4-5 words) | Read aloud, typed on a TV remote or phone |
| One-off password for a throwaway account | Random string | Manager stores it, zero memorability needed |
The split is consistent: the moment a brain is in the loop, words win; the moment it is pure copy-paste or code, random characters win. Notice WiFi sits on the passphrase side even though it is "just a password" — because the failure mode is a guest squinting at a sticky note and typing Il1|O0 wrong four times.
Why Not Just Use Passphrases for Everything?
Because per-character entropy density matters when you are not paying the memorability cost. A 20-character random string from a 95-character set carries about 131 bits. A passphrase matching that needs roughly ten EFF-list words — a 50-to-60-character monster nobody wants pasted into a config file or a vault field. For machine secrets, the random string is shorter, denser, and equally unmemorable, which is exactly what you want there. Save the words for the secrets your brain has to carry. The entropy article works through why length, not symbol-stuffing, is what actually buys you bits.
Why Not Random Strings for Everything?
Because humans are the bottleneck on memorised secrets, and humans degrade random strings in predictable ways. When you force someone to memorise kQ7$mPx2!n3Rv8wL, one of two things happens: they write it on a Post-it (now it is a physical token, not a memorised secret), or they quietly swap it for Summer2026! because they could not cope. A passphrase you can actually remember is stronger in practice than a random string you offload to a sticky note. Security that people route around is not security. That behavioural reality is the entire argument of the diceware guide.
Where Passkeys Change the Picture in 2026
The honest update for 2026: for a growing share of per-site logins, the best answer is neither generator — it is a passkey. WebAuthn passkeys replace the shared-secret model entirely. There is no string to generate, phish, or reuse, because authentication is a public-key challenge bound to the origin. If a site offers passkeys, take them; you remove a whole category of risk.
But passkeys have not eaten the problem, and they will not soon. Three secrets remain stubbornly password-shaped and will for years:
- The password manager / passkey vault master secret. Your passkeys have to live somewhere, and that somewhere is unlocked by something. That something is memorised. It is the highest-value secret you own, and it is a passphrase — eight words, no compromise.
- Full-disk encryption. No passkey unlocks a cold-booted laptop before the OS loads. That is a passphrase, every time.
- Legacy and enterprise systems that will not support WebAuthn this decade. Random strings in the manager, behind the master passphrase.
So passkeys do not retire the two generators — they narrow the random-string generator's job (fewer per-site passwords to mint over time) while leaving the passphrase's job untouched, arguably more important, because the master secret now guards your passkeys too. If anything, 2026 is the year to lengthen your master passphrase, not shorten it.
My Actual Setup
To make this concrete, here is the end-to-end shape I run and recommend:
- One eight-word passphrase as the password manager master key — generated with the passphrase generator, dashes between words, memorised over the first fortnight by typing it manually.
- Passkeys wherever a site offers them, synced through the manager.
- 20-character random strings from the password generator for every site that still wants a password, generated and stored by the manager — I never see or type them.
- 32-character random strings for API keys and service credentials, generated once and pushed straight into the secrets manager.
- A separate passphrase for full-disk encryption, because it has to be typed before the manager is available.
- A hardware key (WebAuthn, YubiKey) as the second factor on the manager itself.
Two passphrases in my head, everything else generated and stored. That is the whole system.
The Rule I Actually Use
Stop choosing generators by feel. Ask the single question — does a human type this from memory? — and the answer picks the tool. Passphrases for the handful of secrets your brain must carry, random strings for the hundreds your manager carries for you, passkeys wherever the site supports them. And in 2026 specifically: lengthen the one passphrase that now guards your passkeys too, because that single secret is doing more work than it ever has. Whichever side you land on, generate it with a real CSPRNG — never your own imagination, and never Math.random().