Strong password regex
12+ characters with upper, lower, digit, and symbol — the familiar 'complex password' rule.
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[\W_])[A-Za-z\d\W_]{12,}$/What it matches
This pattern enforces the classic complex-password rule using four positive lookaheads: at least one lowercase letter, one uppercase, one digit, one symbol, and a minimum length of 12. Modern security guidance (NIST 800-63B) actually de-emphasizes class composition in favor of length and known-compromised-password lists — but the complexity rule is still required by many compliance regimes and remains the most familiar baseline.
Examples
Matches
MyP@ssw0rd!23Upper, lower, digit, symbol, 14 chars.
Tr0ub4dor&3-XYZComplex 15-char password.
aB1!aB1!aB1!Meets all rules — though predictable patterns like this are weak in practice.
Does not match
shortUnder 12 characters.
alllowercase1!No uppercase.
ALLUPPERCASE1!No lowercase.
NoSymbols1234No symbol.
NoDigits!XYZAANo digit.
Edge cases & gotchas
- Defines 'symbol' as `\W_` — anything that's not a word character, plus underscore. Includes most punctuation but not all Unicode symbols.
- Doesn't catch passwords that are technically complex but trivial to guess (`Password1!` passes). Pair with a known-compromised-password list (haveibeenpwned has a free API).
- Doesn't enforce maximum length. The OWASP guidance is to allow at least 128 characters — let users use passphrases.
- Doesn't reject the user's email/name. That check belongs in application code, not regex.
In your language
// JavaScript
const re = /^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[\W_])[A-Za-z\d\W_]{12,}$/;
const match = "input".match(re);All 13 languages (including Bash, Perl, Kotlin, Swift) available in the full toolkit Export tab.
Notes for production
- NIST 800-63B-4 recommends checking against known-compromised password lists rather than enforcing class composition. This regex is the familiar baseline if your compliance framework still requires it.
- For new applications: prefer passkeys (WebAuthn) over passwords entirely. They eliminate phishing, credential stuffing, and password-reuse attacks.
Frequently asked
Why is this stricter than what NIST recommends?
NIST 800-63B-4 (2026) explicitly says class-composition rules don't measurably improve security and frustrate users. They recommend length minimums plus checks against known-compromised lists. This pattern is for organizations whose compliance framework hasn't caught up.
How do I check against known-compromised passwords?
Use the haveibeenpwned Pwned Passwords API — free, k-anonymous (only first 5 SHA-1 hex chars sent), and lists every password in known data breaches.
Should I limit password length?
Limit at a high ceiling (128+ chars) to prevent denial-of-service via huge inputs, but otherwise allow passphrases. Length is the single biggest factor in real-world password strength.