Password Generator FAQ: Everything People Ask About Random Passwords

I've been managing servers and dealing with credentials for years, and I can tell you — the questions people ask about password generators are almost always the same five or six things, recycled endlessly. So let me just answer them all at once, directly, without the fluff.

Is a randomly generated password actually more secure than one I make up?

Yes, and not by a small margin. When you invent a password, you're drawing from a much smaller mental pool than you realize. Humans are terrible at true randomness — we avoid repeating characters, we unconsciously reach for familiar patterns (years, names, keyboard runs like "qwerty"), and we gravitate toward words that mean something to us. An attacker running a dictionary attack or a rule-based mutation engine will find your clever password far faster than you'd expect.

A proper password generator uses a cryptographically secure pseudorandom number generator (CSPRNG) — the same class of randomness used in cryptographic protocols. It has no preferences, no fatigue, no patterns. The output is genuinely unpredictable to anyone who doesn't know the seed state, which is kept internal to the system. That's a fundamentally different security guarantee than your memory-based "Tr0ub4dor&3" approach.

How long does a generated password actually need to be?

The honest answer is: it depends on where you're storing it and what's protecting it, but here's a practical breakdown.

• 16 characters minimum for anything that matters. This puts you in the range of 10²² to 10²⁶ possible combinations depending on character set, which is computationally infeasible to brute-force with current hardware.
• 20–24 characters is a sweet spot for most accounts — long enough to be effectively uncrackable for decades, short enough that paste works fine in almost every password field.
• 32+ characters makes sense for master passwords on your password manager, or for anything that's never typed by hand. There's no downside at this length except the rare badly-coded site that silently truncates input (which is a security bug on their end).

What doesn't work: 8 characters, even with symbols. Modern GPUs can exhaust the entire 8-character alphanumeric+symbol space in hours to days. That was "strong" in 2003. It isn't now.

Do special characters actually help, or is this just a checkbox thing?

Both, honestly. Special characters do increase the character set size, which mathematically increases entropy. If your password is drawn from 26+26+10+32 = 94 possible characters instead of 62 (letters and digits only), each character position carries more entropy. A 16-character password from a 94-character set has roughly 105 bits of entropy versus about 95 bits from a 62-character set. That's a meaningful gap.

BUT — and this matters — the benefit of adding one more character to your password length outweighs the benefit of expanding the character set. A 17-character password from 62 characters is stronger than a 16-character password from 94. So if a site forces you to drop down to 12 characters max, adding symbols helps. If you can choose 24 characters freely, you'd be fine skipping symbols entirely.

The practical problem with special characters is that many sites silently reject certain ones (!&"'@#), some mobile keyboards make them annoying to type, and some terminal/config contexts require escaping. For passwords that get pasted, none of this matters. For passwords you type regularly, it might be worth sticking to letters and digits at a longer length instead.

I generated a strong password — where am I supposed to put it?

A password manager. There's no other sensible answer. Here's why the common alternatives fail:

A text file on your desktop: Unencrypted. One malware infection, one screen-share, one sync to the wrong cloud account, and it's gone. Don't.

Your browser's built-in saving: Better than nothing, but your passwords are typically only protected by your OS login, not a dedicated master password. If someone gets into your logged-in browser session, they can export everything in seconds.

A notes app: Usually unencrypted, often synced to cloud without E2E encryption. Same risks as the text file, just with a prettier icon.

Dedicated password managers (Bitwarden, 1Password, KeePassXC): Your vault is encrypted with a key derived from your master password. Even if the company's servers are breached (it's happened), attackers get an encrypted blob, not your passwords. Use one of these. Bitwarden specifically is open-source and has had independent security audits — I'd suggest it over any closed-source option for anyone who wants to verify what they're trusting.

What's the difference between a password generator and a passphrase generator?

A password generator produces strings of random characters: nK7@xR!2qLpT#mV9

A passphrase generator produces sequences of random words: correct horse battery staple (yes, the xkcd one — it's famous because it's right)

Both can be highly secure. A 4-word passphrase drawn from a 7,776-word list (the EFF Diceware list) has about 51 bits of entropy. A 5-word passphrase has about 64 bits — roughly equivalent to a fully random 10-character password from a 94-character set. A 6-word passphrase exceeds most random character passwords people actually use.

Passphrases win on memorability. If you need to type something in your head or recover access when your password manager isn't available, four or five random words are much easier to recall than 20 random characters. For your password manager master password specifically, a 6-word diceware passphrase is an excellent choice — long entropy, memorable enough to actually remember.

Can I check if my generated password has been leaked in a breach?

You shouldn't check a password you plan to use, because any time you submit a password to a third-party service you're creating exposure risk. But you can safely check email addresses and usernames using HaveIBeenPwned (haveibeenpwned.com). This tells you if your account credentials appeared in a known data breach, which is the more useful signal anyway.

For checking passwords specifically: HaveIBeenPwned offers a Pwned Passwords API that uses a k-anonymity model. You hash your password with SHA-1, send only the first 5 characters of that hash, and the API returns all hashes that start with those 5 characters. Your client checks locally if the full hash matches. The server never sees your actual password or even the full hash. This is genuinely safe to use, and the database contains over 800 million compromised passwords. Some password managers (including 1Password) have this check built in.

Why does my bank still limit passwords to 12 characters with no special characters?

Because the people who built their auth system in 2007 made poor decisions, and migrating legacy systems is expensive and risky. This is a widespread and embarrassing problem in financial services specifically. A short character limit strongly suggests they're storing passwords in a fixed-width column rather than as a hash (which has a fixed output length regardless of input length), which would be a serious security failure — but could also just be an overly restrictive front-end validation rule.

You can't fix this. What you can do: use the maximum length they allow, enable every additional factor they offer (SMS is weak, authenticator apps are better, hardware keys are best), and monitor your accounts. A strong password on a weak system is still better than a weak password.

Does it matter which password generator I use?

Yes. A few things to verify:

Is it client-side? If you're using an online generator, the code should run entirely in your browser (you can disconnect from the internet after the page loads and verify it still works). If the generator sends anything to a server, you've introduced a point of interception.

Does it use a CSPRNG? In JavaScript, this means crypto.getRandomValues(). In Python, secrets.choice(). Not Math.random(), not random.choice(). These non-cryptographic functions use predictable algorithms and are not appropriate for security-sensitive generation.

Is the code auditable? Open-source tools where you can verify the implementation beat black-box tools every time. Your password manager's built-in generator is usually a safe bet since the whole codebase has been reviewed.

The generator baked into Bitwarden, 1Password, or KeePassXC satisfies all three criteria. An unverified browser tab from some random domain does not.

One last thing

The single highest-leverage change most people can make isn't switching generators or going from 16 to 20 characters. It's making sure every account has a unique password. Credential stuffing — where attackers take leaked username/password combos from one breach and try them everywhere else — is the most common account takeover method. A unique password per site means a single breach stays contained. That's the actual win, and it's only manageable at scale with a password manager anyway. So if you take one thing away: get a password manager, let it generate everything, and stop reusing anything.