Build a Password Validation Regex — Free Pattern Generator

Core Password Regular Expression Patterns for Every Use Case

The following four patterns cover the most common password requirements you'll encounter in real-world web development. Each one builds on the last, adding or removing conditions so you can select the version that fits your password policy.

Pattern 1: Minimum 8 Characters with an Uppercase Letter and Lowercase Letter Required

Requirement: Password must contain at least one digit from 0–9, at least one lowercase letter, at least one uppercase letter, one special character, no space, and must be 8–16 characters long.

^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*\W)(?!.* ).{8,16}$

Component breakdown:

• ^ — start of string (caret anchor); without this the engine can match mid-string.
• (?=.*[0-9]) — at least one digit from 0-9 must be present.
• (?=.*[a-z]) — mandatory lowercase letter (at least one lowercase English letter).
• (?=.*[A-Z]) — mandatory uppercase letter (at least one uppercase English letter).
• (?=.*\W) — at least one special character (any non-word character, including non-alphanumeric characters); this is broader than an explicit list and also accepts the underscore special character variant when combined with [_].
• (?!.* ) — negative lookahead enforcing no space and no tab (whitespace restriction).
• .{8,16} — 8-16 characters total, enforcing both minimum characters and maximum length.
• $ — end of string (dollar anchor); together with ^, these boundary anchors ensure the entire string is checked.

Worked Example:

1. Input: P@ssw0rd!
2. Check uppercase: (?=.*[A-Z]) — finds P ✓
3. Check lowercase: (?=.*[a-z]) — finds s ✓
4. Check digit: (?=.*[0-9]) — finds 0 ✓
5. Check special: (?=.*\W) — finds @ ✓
6. Check length: 9 characters, within {8,16} ✓
7. Result: returns true — valid password ✓

Testing password1 fails immediately at the uppercase lookahead, yields a negative result, and the user sees an error before submission.

Pattern 2: Full-Strength Pattern with Uppercase, Lowercase, Digit, and Special Character Required

Requirement: Password must contain at least one uppercase English letter, at least one lowercase English letter, at least one digit, at least one special character from the set [#?!@$%^&*-], and be at minimum 8 characters long with no upper length cap.

/^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{8,}$/

This is the canonical strong password regex pattern. The lazy quantifiers (.*?) inside each lookahead reduce unnecessary backtracking. The explicit special-character set [#?!@$%^&*-] acts as a whitelist characters approach — you allow special characters from a defined list rather than accepting any non-word character. If you need to restrict special characters more tightly (for example, to prevent SQL injection vectors), this explicit set is safer than \W.

Note that .{8,} (the remove maximum length restriction form) replaces .{8,16}. Use {8,16} when you want a character limit of maximum 10 characters or up to 30 characters for storage reasons; drop the upper bound for most modern applications where password length should be unrestricted beyond the minimum.

Worked Example — Full Strength:

1. Pattern: /^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{8,}$/
2. Test string: P@ssw0rd! — all four lookaheads pass, length = 9 ≥ 8 → valid password ✓
3. Test string: password1 — (?=.*?[A-Z]) fails (no uppercase) → does not match ✗
4. Test string: Hello123 — (?=.*?[#?!@$%^&*-]) fails (no special character) → does not match ✗

Pattern 3: Excluding Whitespace and Newlines with a Negated Character Class

Requirement: Password must contain at least one uppercase letter, one lowercase letter, one numeric digit, one special character, be at least 8 characters long, and must not contain any whitespace, including spaces, tabs, or line breaks.

^(?=\S*[a-z])(?=\S*[A-Z])(?=\S*\d)(?=\S*[^\w\s])\S{8,}$

Replacing .* with \S* inside each lookahead and using \S{8,} as the consuming pattern enforces no whitespace at every position — a negated character class technique. The class [^\w\s] matches any character that is neither a word character ([a-zA-Z0-9_]) nor whitespace, covering a broader special characters list than an explicit enumeration. This approach handles non-alpha numeric symbols like (, ), +, and ; without listing them individually. The trade-off: if your system needs to restrict special characters to a known set for input sanitization, an explicit list is safer.

Note: \W in JavaScript matches only ASCII non-word characters, so non-ASCII locale characters will pass the special-character check. In PHP/PCRE with Unicode mode, \W may match a wider range — a reason to test your regex flavor explicitly on regex101 before deployment.

Pattern 4: Removing the Maximum Length Restriction for Unrestricted Strong Passwords

Requirement: Password must contain one digit from 1–9, one lowercase letter, one uppercase letter, and one underscore, with no space. Usage of any other special character and space is optional. There is no upper character limit.

^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z]).{8,}$

By removing both (?=.*_) and (?!.* ) from Pattern 3 and switching to .{8,}, you eliminate both the mandatory underscore special character requirement and the space restriction. This gives users the flexibility to create longer passphrases — for example, CorrectHorseBattery7 — without hitting an arbitrary ceiling. The remove maximum length restriction approach aligns with modern password policy guidance from NIST, which discourages artificial length ceilings on passwords of 8 or more characters.

How to Build and Test Your Strong Password Regex Interactively

A good password validation regex builder compresses what used to be a trial-and-error cycle into a single, unified workspace. Whether you're using an open workspace on regex101 or an embedded expression tester on this page, the workflow is the same: write your pattern, enter test strings, and iterate in real-time.

Writing Your Pattern Step by Step

1. Start with anchors: Type ^ at the very beginning and $ at the end. These start anchor and end anchor tokens ensure full-string matching.
2. Add mandatory character lookaheads: Insert (?=.*?[A-Z]) for mandatory uppercase, (?=.*?[a-z]) for mandatory lowercase, (?=.*?[0-9]) for a required numeric digit, and (?=.*?[#?!@$%^&*-]) for a required special character.
3. Add a whitespace exclusion if needed: Insert (?!.* ) as a negative lookahead assertion to enforce no space. This also blocks no line break and no tab if you use (?!.*\s).
4. Set your length quantifier: Close with .{8,}$ for open-ended password length or .{8,16}$ for a range of 8-16 characters.
5. Roll over tokens in the builder to see inline explanations — each component highlights with a tooltip explaining its role. This contextual help speeds up learn regex workflows enormously.

Using Real-Time Test Strings to Validate Logic

Real-time testing is where a regex tester proves its value. Enter your test patterns — both passing cases (e.g., P@ssw0rd!) and failing cases (e.g., password1, SHORT1!, NoSpecial1) — and watch the match highlight instantly. A proper regular expression tester distinguishes between a full match and a partial match, so you can confirm your anchors are working correctly. For unit tests, create a dedicated test suite with at least one positive and one negative example for each rule: at least one uppercase, at least one lowercase, a required digit, and at least one special character.

Save, Undo, and Redo Your Regex Workflow

Once your pattern passes all your test cases, hit save to persist it to your account library. The builder supports full undo redo history so you can roll back accidental changes without losing your progress. When you share a pattern with a colleague via the permalink system (as used on regex101), you will not be able to edit or delete the shared copy — the recipient gets a frozen snapshot. If you need to collaborate on a modify regex or remove condition task, each person should fork the pattern into their own workspace first. The save patterns feature in the pattern repository creates a searchable patterns index so your team can retrieve checked expressions by name or description rather than hunting through commit history.

Implementing Password Regex in JavaScript and PHP — Code Examples

JavaScript Implementation with RegExp.test() and the passwordRegex.test Pattern

In JavaScript, the cleanest approach for browser-side checking is a named RegExp variable tested with the .test() method. Below is a complete password checking function — an isValidPassword helper — with inline comments explaining each lookahead. This regex example code also doubles as a starting point for jQuery validate password integration via the addMethod handler.

// Strong password regex — JavaScript flavor
// Password must contain: at least one uppercase letter, one lowercase letter,
// one digit (0-9), one special character from [#?!@$%^&*-], minimum 8 chars

var passwordRegex = /^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{8,}$/;

function isValidPassword(password) {
  // (?=.*?[A-Z])  — at least one uppercase English letter
  // (?=.*?[a-z])  — at least one lowercase English letter
  // (?=.*?[0-9])  — at least one digit (0-9)
  // (?=.*?[#?!@$%^&*-]) — at least one special character
  // .{8,}         — minimum 8 characters (no upper length cap)
  return passwordRegex.test(password);
}

// Test cases
console.log(isValidPassword('secret'));      // false — too short, no uppercase, no special
console.log(isValidPassword('-Secr3t.'));    // true  — all conditions met
console.log(isValidPassword('P@ssw0rd!'));   // true
console.log(isValidPassword('password1'));   // false — no uppercase, no special character

For form checking, call isValidPassword() on the input event of your password field. In ASP.NET web forms or jQuery validate contexts, the same pattern can be dropped into the pattern attribute or wrapped in an addMethod handler callback. Always pair browser-side checking with backend checking — never rely on scripting alone for credential protection.

For medium-strength passwords where you only need two of the four character types, use the medium regex approach:

// Medium password regex — requires 2 of 3: uppercase/lowercase, digit — min 6 chars
var mediumRegex = /^(((?=.*[a-z])(?=.*[A-Z]))|((?=.*[a-z])(?=.*[0-9]))|((?=.*[A-Z])(?=.*[0-9])))(?=.{6,})/;

console.log(mediumRegex.test('Hello1'));  // true — medium strength
console.log(mediumRegex.test('hello'));   // false — no digit or uppercase

PHP/PCRE Implementation with preg_match() for Server-Side Validation

On the server side, PHP/PCRE uses preg_match() for regex match operations. The pattern syntax is identical to the scripting version, wrapped in PHP's delimiter convention. PCRE support for all the lookahead constructs used above is comprehensive in PHP 7.x and 8.x.

<?php
// Strong password checking — PHP/PCRE flavor
// Requires: uppercase, lowercase, digit (0-9), special char, min 8 chars

function isValidPassword(string $password): bool {
    $pattern = '/^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{8,}$/';
    // (?=.*?[A-Z])          — mandatory uppercase letter
    // (?=.*?[a-z])          — mandatory lowercase letter
    // (?=.*?[0-9])          — mandatory digit
    // (?=.*?[#?!@$%^&*-])  — mandatory special character
    // .{8,}                 — minimum eight characters, no upper limit
    return (bool) preg_match($pattern, $password);
}

// Test cases
var_dump(isValidPassword('secret'));     // bool(false)
var_dump(isValidPassword('-Secr3t.'));   // bool(true)
var_dump(isValidPassword('P@ssw0rd!')); // bool(true)

// Variant: max 30 characters
$strictPattern = '/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[#$@!%&*?])[A-Za-z\d#$@!%&*?]{8,30}$/';
var_dump(preg_match($strictPattern, 'ValidP@ss1')); // int(1)
?>

The PHP version using preg_match() returns an integer (1 for match, 0 for no match, false on error), so casting to bool produces clean boolean output. This is the server-side counterpart to passwordRegex.test() in JavaScript. Both enforce the same password rules — the only difference is the delimiter and the calling syntax. For ASP.NET implementations, the RegexValidator control accepts the same pattern string with ^ and $ anchors directly.

Advanced Password Validation Regex Builder Techniques and Real-Time Pattern Testing

Beyond the standard four-lookahead pattern, advanced users leverage several techniques to handle edge cases in user authentication, identity management, and access control systems. Understanding these approaches helps you make informed decisions about password enforcement strategy in your application.

The DeMorgan's Theorem Approach — Matching Invalid Passwords Instead

Regular expressions natively support OR logic through alternation but lack a native AND operator. As one highly-upvoted Stack Overflow answer explains, applying De Morgan's theorem lets you invert the problem: instead of matching valid passwords, write a regex that matches invalid ones, then reject any string that matches.

^(.{0,7}|[^0-9]*|[^A-Z]*|[^a-z]*|[a-zA-Z0-9]*)$

Each alternative matches a specific failure mode:

• .{0,7} — password is fewer than minimum characters (less than 8)
• [^0-9]* — password contains no digit from 0–9
• [^A-Z]* — password has no uppercase letters
• [^a-z]* — password has no lowercase letters
• [a-zA-Z0-9]* — password has no special chars (all letters and numbers only)

If this pattern matches, the password is invalid. This approach also has a performance advantage: it uses no lookaheads, making it compatible with browser-side environments where some engines lack full lookahead support. It also covers a broader special character scope, accepting any non-letter-digit characters including uncommon punctuation characters and symbol characters. The downside is that giving users specific error messages ("you need an uppercase letter") requires testing each alternative branch separately — a task better suited to an imperative password checker or a password strength meter widget.

Handling Password Strength: Strong Regex vs Medium Regex

Not every application needs a strong regex. A tiered approach with a medium regex and a strong regex gives you a credential-strength gradient, allowing users to see a visual indicator rather than a binary pass/fail. Use the medium regex (requiring any two of uppercase/lowercase/digit) for an initial tier, then the full four-condition pattern for maximum protection. This is what a proper strength meter implements under the hood — and understanding the underlying regex pattern matching lets you customize thresholds for your specific password policy.

Keep in mind that regex enforces password complexity rules but cannot measure true randomness — a 12-character password of Aaaa1111!!!! passes all four conditions but is far weaker than a random 12-character string. Supplement regex password enforcement with a dedicated protection library that checks against commonly used passwords, measures actual unpredictability, and flags predictable password conditions like keyboard walks and dictionary words. For robust web protection, credential safeguarding, and account safety, regex is the first gate — not the last line of defense against brute force attacks.

HTML5 Pattern Attribute and ASP.NET Regex Validator Integration

The HTML5 pattern attribute accepts a regex directly on the <input> element, enabling browser-native form checking without any scripting code. For a strong password field: <input type="password" pattern="(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{8,}" required>. Note that the pattern attribute checking automatically anchors the pattern to the full string (no ^ or $ needed in HTML5). In ASP.NET, the RegularExpressionValidator control uses the same syntax with explicit anchors and checks on both client and server, satisfying data checking, string checking, and form checking requirements in a single control. For jquery validate password using $.validator.addMethod, pass the regex .test() call as the checking function body — the addMethod handler pattern integrates cleanly with existing form libraries.

Whichever implementation path you choose — native HTML5, scripted RegExp, PHP/PCRE preg_match(), or ASP.NET — the underlying pattern remains identical. Build it once in a password validation regex builder, verify it with pattern testing across both valid and invalid strings, save it to your regex library, and share the regex code snippet as a reusable code snippet across your entire development team for consistent password rules enforcement across every web forms and user input surface in your application.