Website rejects a new password that seems strong enough

TL;DR — If your website rejects a password that looks strong, the most common cause is that the site has stricter password rules than the form explains, or the browser pasted hidden characters or mismatched values into the fields. Start by testing a manually typed password that uses only letters, numbers, and one common symbol, then check your app's password policy settings and any security plugin or identity provider rules. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon: you are setting a new password for your own account, or helping a client reset theirs, and the site keeps saying the password is invalid. The password looks fine — it is long, mixed case, includes numbers, and even a symbol — but the form still refuses it with a vague message like "Password does not meet requirements." You try again in another browser, then copy-paste a different one from your password manager, and now you are not sure whether the problem is the browser, the site, or some hidden rule nobody documented. Meanwhile, the user is blocked from logging in and waiting for an answer.

Symptoms

• The form shows messages such as:
  • "Password does not meet requirements"
  • "Password is too weak"
  • "Password contains invalid characters"
  • "Passwords do not match"
  • "Unable to reset password"
• The page accepts the reset token or opens the reset form, but rejects the new password on submit.
• The same password works on another site, but not on this one.
• A password manager generates a password that is rejected, while a simpler manually typed password works.
• Browser developer tools (the browser's built-in page inspector) may show a failed request with:

HTTP/1.1 400 Bad Request

or

HTTP/1.1 422 Unprocessable Entity

• Application logs may contain lines like:

password validation failed: missing required character class

password policy violation: contains unsupported unicode characters

reset password failed: password history check rejected reuse

validation error: password and confirmation do not match

Likely causes

Step-by-step diagnosis

1. Check the exact error text on the form.

   • Action: Reproduce the issue and copy the full message shown under the password field or at the top of the form.
   • This is your problem if: the message mentions a specific rule such as length, symbol, reuse, or mismatch.
   • Jump to: the matching fix section below.

2. Try a manual, simple-strong test password.

   • Action: In a private/incognito window, type this manually into both fields:

BlueRiver42!Maple

• This is your problem if: this password works, but pasted or generated passwords do not.
• Jump to: ### Hidden characters or unsupported symbols were pasted from a password manager, or ### Browser autofill filled the confirmation field differently.

1. Check whether the site has stricter password rules than the page says.
   • Action: In your provider's dashboard or CMS admin area, open the authentication settings. Common paths are one of these, depending on your system:

Admin → Settings → Security
Admin → Authentication → Password Policy
Admin → Users → Password Rules

• This is your problem if: the configured rules require more than the form explains, such as "minimum 16 characters," "must include 3 of 4 character types," or "symbols limited to ASCII only."
• Jump to: ### Password policy is stricter than the form explains.

1. Rule out password reuse or common-password blocking.
   • Action: Try a completely new password that is unlikely to be in history and is not a common pattern, for example:

CedarWindow84!Orbit

• This is your problem if: older favorites keep failing but a brand-new one works.
• Jump to: ### Password history or breach check is blocking reuse/common passwords.

1. Test for length or character-set bugs.
   • Action: Try these two passwords, typed manually:

Short test: BlueRiver42!
Long test: BlueRiver42!MapleStoneRiverCloud7

• This is your problem if: one length works and the other fails, or passwords with accented letters/emojis fail while plain English characters work.
• Jump to: ### The app is misconfigured and rejects long passwords or Unicode characters.

1. Check plugins, custom code, or an external identity provider.
   • Action: If your site uses a security plugin, membership plugin, SSO (single sign-on), or external login provider, review its password policy page first. Common places:

Admin → Plugins → [security or membership plugin] → Settings
Identity provider dashboard → Security → Authentication → Password policy

• This is your problem if: the app's own settings look fine, but the plugin or identity provider has a stricter rule.
• Jump to: ### A plugin, custom validation rule, or external identity provider is enforcing extra rules.

[User Browser] ---- 1. submit new password ----> [Website]
      |                                         |
      v                                         v
[Autofill/Paste]                         [Password Policy]
      |                                         |
      v                                         v
[Hidden chars or mismatch] <---- 2. reject ---- [Plugin/IdP]

Fixes

Password policy is stricter than the form explains

Update the policy text shown to users so it matches the real rule, or adjust the rule to what you actually want.

• Dashboard path: open your app's password settings page, then either:

Admin → Authentication → Password Policy

or

Admin → Settings → Security → Password Requirements

• Set a clear policy such as:

Minimum length: 12
Require uppercase: On
Require lowercase: On
Require number: On
Require symbol: On
Allow pasted passwords: On

• If your app stores policy in environment variables or config, look for values like these and align them with the UI text:

{
  "passwordMinLength": 12,
  "requireUppercase": true,
  "requireLowercase": true,
  "requireNumber": true,
  "requireSymbol": true
}

Verify it worked: the form accepts a password that matches the displayed rules, and the error message now matches the actual requirement.

Hidden characters or unsupported symbols were pasted from a password manager

Some forms reject spaces, smart quotes, non-Latin characters, or invisible characters copied during paste.

• Ask the user to type the password manually once in a private/incognito window.
• If they use a password manager, regenerate using only standard ASCII characters (plain English letters, numbers, and common symbols). A safe pattern is:

Three random words + numbers + one symbol
Example: CedarWindow84!Orbit

• If your password manager has an options screen, turn off these options for this test:

Ambiguous characters
Extended symbols
Unicode characters

Verify it worked: a manually typed ASCII-only password is accepted, while the previously pasted one was not.

Browser autofill filled the confirmation field differently

Autofill can populate one field with an old saved value and the other with the new one, even when they look similar on screen.

• Open a private/incognito window.
• Go to the reset page again from the email link or reset flow.
• Type both fields by hand; do not use autofill.
• If needed, clear the saved password for that site in your browser's password manager settings.

Common browser path examples:

Browser Settings → Passwords / Password Manager → search for your site → remove saved entry

Verify it worked: the same password succeeds when typed manually in a private/incognito window.

Password history or breach check is blocking reuse/common passwords

Many systems block recently used passwords or passwords found in common-password lists.

• Choose a completely new password, not a variation of the old one.
• Avoid patterns like these:

OldPassword1! → OldPassword2!
CompanyName2026!
Summer2026!

• Use a new passphrase-style password instead:

LanternHarbor57!Cactus

• In your admin/security settings, review options like:

Prevent reuse of last N passwords
Block compromised passwords
Block common passwords

If users are unexpectedly blocked, reduce an overly strict history value only if your security policy allows it.

Verify it worked: a brand-new password is accepted, while reused or predictable passwords are rejected.

A plugin, custom validation rule, or external identity provider is enforcing extra rules

A membership plugin, custom form validator, or external login provider can override the main app's password rules.

• Dashboard path for site plugins:

Admin → Plugins → Installed Plugins

• Open any security, membership, SSO, or user-management plugin and review its password settings.
• If safe in a staging site first, temporarily disable the plugin and retest.

⚠️ Disabling an authentication or security plugin can lock users out or weaken protection. Test on a staging site first, or do this during a maintenance window.

• For external identity providers, check the provider dashboard path similar to:

Security → Authentication → Password Policy

• If you have developer help, search the codebase for custom validators such as:

grep -Rin "password" .

Verify it worked: once the plugin rule is changed or the custom validator is removed, the previously rejected password is accepted.

The app is misconfigured and rejects long passwords or Unicode characters

Older apps or custom validators sometimes cap password length incorrectly or reject non-ASCII characters.

• Test with a 14-20 character ASCII-only password:

BlueRiver42!Maple

• If that works, avoid accented letters, emojis, or unusual symbols until the app is fixed.
• Ask your developer or hosting team to review the server-side validator for:

Maximum length limits that are too low
Regex (pattern-matching rule) that allows only limited symbols
Character encoding not set to UTF-8

• If you can edit config, look for validation patterns like this and widen them carefully:

{
  "passwordRegex": "^(?=.{12,128}$)(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*[^A-Za-z0-9]).*$"
}

Verify it worked: both normal long passwords and your expected symbol set are accepted consistently.

Prevention

• Show the real password rules next to the field, not just after failure. Example helper text:

Use at least 12 characters, including uppercase, lowercase, a number, and a symbol.

• Add a client-side and server-side test in CI (continuous integration, your automated checks) for the same sample passwords:

[
  "BlueRiver42!Maple",
  "CedarWindow84!Orbit",
  "LanternHarbor57!Cactus"
]

• Add an automated test for paste/autofill edge cases in your form tests:

Test 1: typed password matches confirmation
Test 2: pasted password matches confirmation
Test 3: unsupported Unicode returns clear error text

• Log password validation failures by reason, without logging the password itself. Example log format:

{
  "event": "password_validation_failed",
  "reason": "history_reuse",
  "user_id": 12345
}

• If you use a plugin or external identity provider, document the single source of truth for password policy in your internal runbook:

Password policy owner: Identity provider
Website form text must match IdP policy exactly

• Before enabling stricter rules, test generated passwords from at least one major browser and one password manager to confirm the form accepts them.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.