Password Requirements Example
Last updated: September 2026
A typical password requirements example looks something like this: "at least 8 characters, one uppercase letter, one number, one special character." Here's what those requirements are actually trying to accomplish, and where they fall short.
What a typical requirement looks like
| Requirement | Example that satisfies it |
|---|---|
| 8+ characters, 1 uppercase, 1 number | Riverbank7 |
| 12+ characters, 1 symbol, 1 number | Meadow-Falcon42! |
| 15+ characters, no character-class rules (NIST-aligned) | correct-battery-lagoon-shale |
| 20+ characters, uppercase + lowercase + number + symbol (legacy enterprise-style rule) | Tw!light-Harbor-42-Ferns |
Note that satisfying a rule isn't the same as being strong — Riverbank7 technically meets the first requirement above but follows a predictable "word + capital + digit" pattern that's easy to guess.
Why services set these rules
Character-class requirements exist mainly to stop the weakest possible passwords — password, 12345678 — from being accepted at all. They're a floor, not a strength guarantee. A password can satisfy every rule on the list and still be weak if it follows a predictable pattern.
What NIST actually requires now
NIST SP 800-63B Revision 4, finalized in July 2025, is the current version of the federal guidance most password-policy advice traces back to. It's more specific — and stricter on length — than most people expect:
- Services SHALL require at least 15 characters when a password is your only login factor (no second factor like an app code or security key).
- Where a password is paired with a second factor, the minimum drops to 8 characters.
- Services SHOULD support passwords of at least 64 characters — there's no good reason to cap you well below that.
- Services SHALL NOT require a mix of character types (uppercase, lowercase, number, symbol) as a condition of accepting a password. That requirement is now explicitly disallowed, not just discouraged.
- Services must screen new passwords against a blocklist of known-breached, dictionary, and context-specific passwords (ones based on the service's own name, for example) and reject a match.
"SHALL" is the standard's word for mandatory; "SHOULD" is a strong recommendation a service can deviate from with justification. Most consumer sites still haven't caught up to this revision, which is exactly why you'll keep running into 8-character minimums and forced-symbol rules for a while yet.
Where character rules fall short
- They don't stop predictable substitutions like P@ssw0rd, which satisfies most rule sets while being one of the first guesses any cracking tool tries.
- They can push people toward shorter passwords, since meeting four separate rules in a short string feels "done" even though length matters more.
- Some services cap the maximum length surprisingly low — 20 or 32 characters isn't unusual — because of how their password hashing works. Bcrypt, a widely used hashing algorithm, silently truncates anything past 72 bytes, so some services cap input at or under that rather than let you type characters that would never actually be checked.
- NIST's current guidance (SP 800-63B Rev. 4) recommends against mandatory periodic password changes entirely, and now flatly prohibits complex composition rules, favoring length and screening against known-breached passwords instead.
Meeting a strict requirement without weakening your password
If a site insists on a mix of character types, our generator's Random mode already guarantees at least one character from every class you enable, so turning on uppercase, numbers, and symbols satisfies that kind of rule automatically — no need to bolt on a predictable ! or 1 yourself afterward.
For rules that go further — "must start with a letter," "can't end in a number," "no ampersands allowed" — the generator's Custom Requirements section lets you fix the first character, fix the last character, and exclude specific characters entirely, then fills in the rest randomly. You get a password that satisfies the exact rule in front of you without resorting to a pattern a cracking tool has seen a million times.
Frequently asked questions
Does meeting the character requirements mean my password is strong?
Not necessarily. Requirements set a minimum floor, but a password that satisfies every rule can still follow a predictable pattern that's easy to guess. Use the entropy calculator to check the real strength.
Why do some sites still require special characters if NIST says it's not necessary?
Many services haven't updated their password policies to match current guidance. When a site requires it, our generator can include symbols so you satisfy the rule without falling back on predictable substitutions.
What's the actual minimum length I should use?
15 characters if the password is your only login factor — that's NIST's current mandatory minimum, not just a suggestion. We'd round up to 16+ where the service allows it. See our full guide for the complete picture.
Why does this site cap my password at such a low maximum length?
Usually because of how the service stores passwords, not a security choice you can work around. Bcrypt, a common password-hashing algorithm, ignores anything past 72 bytes, so some services cap input at or below that rather than accept characters that would never actually be checked.