The honest answer is "it depends on what you're protecting" β a forum login and a cryptocurrency wallet don't carry the same risk if compromised, so they don't need the same password length. This article gives concrete length targets by account type, and explains why current guidance favors length over composition rules like mandatory symbols.
TL;DR
- NIST SP 800-63B recommends allowing (and encouraging) long passwords rather than enforcing complexity rules like mandatory symbols.
- 16 characters is a reasonable default for most accounts; 20+ for anything protecting money or identity; 24-32+ for a password manager's Master Password.
- Length increases your protection exponentially; each mandatory character-type rule adds comparatively little. See Password Entropy Explained for the math.
- Length only helps if the characters are genuinely random β a long but predictable password (a sentence, a keyboard pattern) doesn't get the full benefit.
Short Answer
Use at least 16 characters for most accounts, 20+ for financial or identity-critical accounts, and 24-32+ for your password manager's Master Password or any other single point of failure. PassGenerate lets you set length directly and defaults to 16, which covers the common case; increase it for higher-stakes accounts.
Recommended Length by Account Type
| Account type | Suggested length | Why |
|---|---|---|
| Low-risk forum or newsletter account | 12-16 characters | Low consequence if compromised; still worth avoiding trivial guessing |
| Email and cloud storage | 16-20 characters | Email is often the recovery path for everything else β compromise here cascades |
| Banking and financial services | 20-24 characters | Direct financial exposure; institutions increasingly enforce longer minimums anyway |
| Admin accounts, crypto wallets, password manager Master Password | 24-32+ characters | Single point of failure β compromise here can expose everything downstream |
| Memorable passphrase (when you must type it often, from memory) | 4-6 random words | Comparable or better entropy than a shorter symbol-heavy password, easier to type accurately |
Why NIST Moved Away from Forced Complexity Rules
Older password policies β a mandatory uppercase letter, a mandatory digit, a mandatory symbol, mandatory rotation every 90 days β were well-intentioned but backfired in practice. Forced complexity pushes people toward predictable patterns (Summer2024!, Password1@) that satisfy the rule while adding little real entropy, and forced rotation pushes people toward incrementing a digit (Password1, Password2) rather than choosing something genuinely new.
NIST formalized this shift in SP 800-63B Revision 4, published in 2025: services must allow passwords of at least 64 characters and must accept spaces and the full range of printable characters; if a password is the only authentication factor, NIST now sets a 15-character minimum, dropping to 8 characters when it's paired with multi-factor authentication. Revision 4 goes further than earlier guidance by explicitly prohibiting mandatory composition rules (required uppercase, digits, symbols) rather than merely discouraging them, and it directs services to check new passwords against breached-password lists instead. It also drops mandatory periodic rotation entirely β passwords should be changed when there's actual evidence of compromise, not on a fixed calendar. The security lever that actually works is length combined with genuine randomness, not a checklist of required character types.
Does Length Alone Guarantee Safety?
No β length only helps if it comes with real randomness. aaaaaaaaaaaaaaaaaaaa (20 characters) is trivially guessable despite its length, and a 20-character sentence pulled from a well-known book is guessable via dictionary attacks built on common phrases. The length recommendations above assume the characters are generated by a cryptographically secure pseudorandom number generator (CSPRNG), the way PassGenerate does it, or drawn from a genuinely random word list for passphrases β not chosen to be memorable, which almost always means less random than it looks.
A Practical Way to Apply This
You don't need to calculate entropy by hand every time. As a working rule:
- Ask what happens if this specific account is compromised β is it annoying, or is it a cascading disaster?
- Pick a length from the table above based on that answer.
- Generate it randomly rather than composing it yourself β length only pays off with real randomness behind it.
- For accounts you must type from memory often, use a random passphrase instead of a random character string β comparable security, meaningfully easier to type correctly.
Key Takeaways
- Password length should scale with what's actually at stake if the account is compromised, not be a single fixed number for everything.
- NIST SP 800-63B favors longer minimums and breach-list checking over mandatory character-composition rules.
- Length alone isn't sufficient β it must be paired with genuine randomness (CSPRNG-generated or a random word list) to deliver the security it implies.
- 16 characters covers most everyday accounts; go to 24-32+ for your password manager's Master Password specifically.
Why You Can Trust PassGenerate
- Passwords are generated locally in your browser using the Web Crypto API.
- No passwords are transmitted to servers.
- Uses a cryptographically secure pseudorandom number generator (CSPRNG).
- Follows modern security best practices recommended by NIST and OWASP.
References
- NIST SP 800-63B Revision 4 (2025) β Digital Identity Guidelines
- OWASP Authentication Cheat Sheet
- CISA Password Guidance
Bottom Line
There's no single right password length β there's a right length for each account's risk level. Sixteen characters is a reasonable floor for most accounts, financial and identity-critical accounts deserve 20+, and anything that acts as a single point of failure (a password manager's Master Password especially) deserves 24-32 or more. None of that matters, though, unless the characters are actually random β length is the multiplier, but randomness is what it's multiplying.