P@ssw0rd! satisfies the composition rules of nearly every website on Earth: uppercase, lowercase, digit, special character. It is also among the first few thousand guesses in any competent cracking run. That single example contains the entire truth about special characters: they can add real strength, and the way humans actually deploy them adds nearly none. The gap between those two facts explains twenty-five years of frustrating password rules - And why the security field has quietly walked away from them. Let's do the actual arithmetic.
What symbols are worth on paper
Password strength is entropy: length × log₂(pool size), measured in bits, where every added bit doubles an attacker's work. Symbols enter that formula only through pool size - And logarithms are cruel to pool size.
Go from lowercase letters (26) to letters-plus-digits (62) to the full printable-ASCII set (95), and the per-character yield moves from 4.70 to 5.95 to 6.57 bits. The entire symbol arsenal - All 33 punctuation marks - Buys you about 0.6 bits per character over letters-and-digits. Meanwhile, one additional character at full pool buys 6.57 bits. One extra character outperforms the whole symbol set applied to a 10-character password:
So symbols aren't worthless - 6 extra bits is a 64× harder search - But they're the smallest lever on the panel. Length dominates, and it isn't close. The full derivation lives in password entropy explained.
What symbols are worth in practice: much less
The math above assumes symbols appear in random positions with random identity. Humans do neither. Decades of breach data show symbol usage collapsing into a handful of patterns:
- Position: overwhelmingly at the end, occasionally replacing a letter mid-word. The classic template is
Word + digits + symbol. - Identity:
!dominates, followed by@,#,$,.- A few characters carry most of the load. - Substitutions:
a→@,e→3,i→1,o→0,s→$- Leetspeak so canonical it has been in cracking tools since the 1990s.
Cracking rule sets encode every one of these habits. To a rig running mangling rules over breach-derived wordlists, Summer! costs barely more than summer, and p@$$w0rd is not meaningfully harder than password - The substitution rule is one line. The mechanics of rule-based guessing are laid out in dictionary attacks; the takeaway here is that a symbol only carries its theoretical 6.57 bits when its position and identity are random. A predictable symbol in a predictable spot carries roughly two bits - The cost of the rule that generates it.
A symbol is worth 6.6 bits when dice placed it and about 2 when you did. Complexity requirements can't tell the difference - Attackers can.
This is why composition rules underdelivered for twenty years: they mandated the appearance of randomness while leaving the generation process human. Users satisfied the letter of the rule in the statistically obvious way, attackers updated one config file, and net security barely moved. Look at any leaderboard of the most common passwords and you'll find rule-compliant entries like P@ssw0rd and Abc123! sitting proudly among the wreckage.
What the standards say now
NIST SP 800-63B - The document US password policy increasingly follows - Is blunt about this history. It recommends that services should not impose composition rules (no "must contain a special character"), and instead emphasizes: length as the primary strength factor, support for passwords up to at least 64 characters, allowing all printable characters including spaces, and screening candidates against known-breached password lists. Microsoft and the UK's NCSC give materially identical advice. The institutions that invented mandatory symbols have formally retired them.
Websites lag standards by years, of course, so you'll be meeting symbol requirements for a long time yet. The point isn't to fight them - It's to stop believing they're what makes you safe.
The right way to use symbols
None of this means avoiding symbols. Inside a randomly generated password, every character class earns its full theoretical value, so the optimal everyday password is exactly what a password generator produces with all sets enabled: 16–20 characters drawn uniformly from the whole pool, ~105–131 bits, satisfying every composition rule on Earth as a side effect rather than a goal.
Practical guidance by situation:
- Site requires a symbol, you're generating: nothing to do - Random generation includes them naturally.
- Site forbids certain symbols (depressingly common, often a sign of fragile legacy code): regenerate with the allowed set and add a couple of characters of length to compensate. Length launders every pool restriction.
- Memorized passphrases: your strength is word count, not decoration. Add one symbol as a separator or suffix to satisfy checkers -
crimson-valley-otter-fable-dune-9!- And count it as compliance, not entropy. - WiFi passwords: skip exotic symbols entirely; you'll be reading this string aloud to guests and pecking it into a TV. A WiFi password generator balances entropy against enter-ability on devices without a real keyboard.
- Testing a candidate: a password strength checker that models dictionaries and patterns (rather than counting character classes) will show you the gap between
Tr0ub4dor&3and twelve random characters instantly - An educational thirty seconds.
The comparison that settles it
| Password | Meets complexity rules? | Approx. real entropy | Offline crack outlook |
|---|---|---|---|
P@ssw0rd! |
Yes | ~5 bits | Instant - Top of every wordlist |
Sunshine2026! |
Yes | ~25 bits | Seconds to minutes with rules |
sunshinemeadowriver |
No | ~35 bits* | Hours-to-days - Word-combo attacks |
chapel-mint-orbit-lava-crisp-nine |
No | ~77 bits | Effectively never (random words) |
fY7#pW2m$kQ9xL4v |
Yes | ~105 bits | Effectively never |
*Human-picked related words; randomly chosen words would rate far higher. Notice that the two safe rows earn safety the same way - Randomness and length - And that rule compliance appears in both the best and worst rows. The rules measure the wrong thing. A step-by-step method for landing in the safe rows is in how to create a strong password.
FAQ
Should I include special characters in my passwords or not?
Yes - Inside randomly generated passwords, where they contribute their full value and cost you nothing. What you should stop doing is hand-placing a symbol to upgrade a word-based password; that adds a bit or two at most. The rule of thumb: symbols chosen by a generator help; symbols chosen by a human mostly signal which mangling rule to apply.
Which special characters are the strongest?
None - No symbol is inherently stronger than another, since each is just one member of the pool. ! is weaker than ~ only in the sense that humans overuse it, making it cheaper in cracking rules. In a randomly generated password the distinction vanishes entirely. Strength lives in randomness and length, never in the exoticness of a particular squiggle.
Why do sites still require symbols if NIST says not to?
Inertia, liability optics, and old compliance checklists. Password policy is rarely revisited once shipped, many audit frameworks still enumerate character classes, and "we require complexity" remains an easy box to tick. Standards changed in 2017; the long tail of implementations will take another decade. Meet the requirement via random generation and move on.
Do spaces count as special characters?
Where allowed, a space is simply one more pool member - And NIST explicitly says services should accept it, which makes multi-word passphrases typeable naturally. Support in the wild is inconsistent, though, and a trailing space is an infamous source of mysterious login failures. Hyphens between passphrase words deliver the same readability with none of the edge cases.
Are Unicode characters like é or 🔑 good password material?
Theoretically superb - The pool explodes. Practically hazardous: sites normalize, reject, or corrupt non-ASCII input inconsistently, different keyboards encode the "same" character differently, and you may be unable to type your own password on a hotel machine or game console. Get your entropy from length within plain ASCII; it's the portable path to the same bits.