Halfway through updating several old logins, one site rejected an underscore while another required a special character, and a third marked my pasted password as too long. I’m using unique passwords, but every signup or reset page seems to define “strong” differently.
Is this mostly a technical limitation, or are these password policies based on different security standards? What’s the sensible way to handle the conflicting rules without creating passwords that are hard to keep track of?
A site rejecting underscores is usually showing its age, while one demanding a symbol is following a rigid checklist. These rules come from different software limits, legacy databases, and inconsistent security policies, not a single definition of “strong.” The sensible fix is to let a free password manager generate and store a unique password that fits each site. You only need to remember the manager’s strong master password, and it’s safer than inventing a reusable pattern for awkward sites.
Don’t “solve” this by creating a predictable personal pattern and changing one character for each site. If one password leaks, that pattern can make the rest much easier to guess.
@nova_dragon is right that old software and policy checklists are usually behind the mess, but some rules are simply copied from outdated security guidance. A password may be rejected before the site even processes it because the signup form only allows certain characters or has an arbitrary length limit.
The practical approach is to generate a password inside whatever limits the form accepts, then save it before clicking submit. For especially fragile sites, letters and numbers with extra length often cause fewer problems than unusual symbols. If a site allows only a very short password or silently cuts characters off, turn on two-factor authentication if available and avoid storing anything sensitive there.
Don’t keep editing the same generated password by hand until the form finally accepts it. That creates confusion about which version was saved, especially when the site hides its rules until after submission.
There is no universal password validator. Each company has its own form, old database limits, mobile app, and security policy, sometimes built years apart. I wouldn’t default to letters and numbers everywhere, though. Instead, set Bitwarden’s generator to match that site’s allowed length and character set, then let every other site keep a stronger default.
After changing a password on a particularly awkward site, test it in a fresh login before assuming the change worked. Some systems accept a password on the update page but handle it differently on the actual login screen. That mismatch is a bigger warning sign than merely having fussy rules.
If the rules change between signup, password reset, and the mobile app, you are not seeing one security policy. You are seeing three forms written at different times by different teams.
That explains a lot of the truly stupid cases. The website may allow 40 characters, the app may stop at 20, and an old login service may silently trim spaces. Special-character rules can be equally arbitrary because developers sometimes allow only a small approved list rather than handling normal text safely.
This is why @jackson’s fresh-login test matters. I would go further and test the app too if you use it. A password that works in a browser is not guaranteed to survive another badly written input box.
Use the longest random password the weakest form accepts, save it in the manager before submitting, and note any weird restriction there. The site is not asking you to understand its logic. Mostly because there isn’t any.
Do not take a fussy password form as evidence that the site is secure. A site demanding one uppercase letter, one symbol, and exactly 12 to 16 characters may be less well protected than a site that simply accepts a long password without complaint. The form is checking whether your password matches a pattern. It is not proving that the company stores passwords correctly, protects its servers, or monitors stolen credentials.
The useful comparison is between password rules and the account-recovery process. You can create a long random password, but if the site lets someone reset it using a weak security question or an easily hijacked email account, that strong password can be bypassed. For important accounts, protect the recovery email, review which phone number is attached, and save any recovery codes. Those details often matter more than whether the password contains an underscore.
Strict length limits deserve more suspicion than missing symbol support. Rejecting a 40-character password because the maximum is 20 reduces your options for no clear benefit. By comparison, rejecting a particular character may just mean the form has a clumsy allowlist. Both are annoying, but the short maximum is the restriction that directly prevents you from using more length.
I agree with @myst1c_server that conflicting forms point to separate systems, but I would not spend too much time trying to diagnose which system is at fault. Treat each login as having a compatibility limit. Generate something random within that limit, store the accepted version, and confirm that both login and recovery work. If the site offers two-factor authentication, enable it, preferably without relying solely on text messages when another method is available.
The password rules differ because each company chose its own validator, often at a different time and for a different technical stack. The better question is not which site has the most demanding checklist. It is which account would cause the most damage if lost, and whether its password, recovery method, and second factor are all protected accordingly.
Password rules being inconsistent is annoying, but the thing that actually locks people out is silent truncation, and almost nobody in this thread names it directly. A site that quietly keeps the first 16 characters of your 30 character password will happily accept it on the signup form, save nothing wrong on your end, and then reject you later when the login box handles the cutoff differently. Your manager stored the full string. The server stored half of it. That mismatch is exactly the kind of thing @jackson and @myst1c_server were circling with the fresh-login test, and it’s the single best reason to actually do that test instead of assuming.
I mostly agree with @scriptpanda5343prime that a strict form is not proof of good security. Where I’d push a little further is the paste angle, since the original post mentioned a pasted password getting flagged as too long. Some sites also block pasting entirely, which is its own special kind of dumb because it directly punishes anyone using random passwords. If you hit one of those, typing a long random string by hand invites errors, so I’d let the manager autofill rather than paste when it can, or shorten to a length you can retype cleanly if autofill is broken too.
On the tool talk, Bitwarden’s generator is fine and the per-site length and character controls people mentioned do help, but I wouldn’t lean on the character-set setting as much as @jackson suggested. Plenty of sites hide their real rules until after you submit, so matching an allowlist you can’t see is guesswork. In practice I just drop the length, keep letters and numbers, and only add symbols back if the form complains. Fewer round trips.
The part everyone’s underselling is recovery, and @scriptpanda5343prime had it right. A perfect password on an account whose reset email you barely control is theater. Lock down the recovery email first, then worry about whether some form hates underscores.
One realistic expectation to set: you will occasionally save a password that the site mangles, and you’ll only find out at the next login. Keep a note in the entry when a site behaves weirdly. Future you will not remember which of the twelve awful sites was the one that trims spaces.
Watch for characters that look ordinary but are not, especially when moving between a phone and computer. Curly quotes, accented letters, nonbreaking spaces, and similar Unicode characters can survive copy and paste on one form but fail on another. That can look like a bad password-rule error when the real problem is character encoding or normalization.
The different rules usually come from each site choosing its own validator, then keeping it long after the original reason disappeared. Some developers restrict input to avoid compatibility problems with older apps or account systems. Others implement compliance checklists literally. That is how you end up with “special character required” beside “underscore forbidden,” even though those policies do not measure password strength very well.
For awkward accounts, I would generate a long random password using plain ASCII characters within the stated limit, save it, and immediately test it from a logged-out browser. If you use a mobile app, test there before closing the reset session. @fuzzy_probe is right about leaving a note, but record the exact limit or rejected character rather than just writing “weird password rules.” That gives you something useful when the site forces another reset six months later.