Password Policy Generator
Generate a password policy and its rules for your service.
The password policy generator turns a few choices — minimum length, character class requirements, maximum age, account lockout threshold and whether MFA is required — into a human-readable password policy plus a matching client-side validation regular expression. It outputs both Korean and English wording that you can paste straight into a security policy document, a sign-up form, or a development spec.
Everything runs entirely in your browser and no input ever leaves the page. Use it when you want to follow modern NIST guidance — prioritising length and avoiding forced periodic changes — while still expressing the minimum requirements your organisation needs in clear, copy-ready language.
| Minimum length | 12 |
|---|---|
| Required classes | uppercase, lowercase, digits |
| Maximum age | no rotation |
| Lockout | after 5 failures |
| MFA | required |
- Passwords must be at least 12 characters long. - Must contain at least one uppercase letter (A–Z). - Must contain at least one lowercase letter (a–z). - Must contain at least one digit (0–9). - No periodic forced change is required unless there is clear evidence of compromise. - Accounts are temporarily locked after 5 consecutive failed logins. - Multi-factor authentication (MFA) is required for all accounts.
^(?=.*[A-Z])(?=.*[a-z])(?=.*\d).{12,}$What goes into the policy
The tool builds a policy from five dimensions. Each becomes a bullet in the generated wording, and the character-class requirements are also compiled into a regular expression you can drop into a sign-up form.
- Minimum length: the fewest characters allowed. Length is the single strongest factor.
- Character classes: which of uppercase, lowercase, digits and symbols are required.
- Maximum age: how many days before a change is required (0 means no rotation).
- Account lockout: how many failed attempts before the account is locked.
- MFA: whether multi-factor authentication is mandatory.
NIST guidance: length first, avoid forced rotation
The US NIST Digital Identity Guidelines (SP 800-63B) argue that adequate length is far more effective than stacking up complexity rules. The key recommendations are:
- Allow at least 8 characters, and ideally long passphrases up to 64 characters.
- Rules that force specific character classes tend to produce predictable patterns such as
Password1!. - Do not require periodic forced changes unless there is clear evidence of compromise. Frequent rotation leads to weaker passwords.
- Screening against known-breached passwords and adding MFA is more effective than complexity rules.
This generator lets you set the maximum age to 0 (no rotation) so your policy can stay aligned with that guidance. Apply the validation regex it outputs alongside the wording to your sign-up form to handle both authoring the policy and validating it on the client in one place.
How to use the generated regex
The regex validates the selected character-class requirements together with the minimum length on the client. Each class is expressed as a lookahead — for example, at least one uppercase letter is (?=.*[A-Z]). Treat it as instant form feedback only; real authentication must re-validate length, breach status and more on the server.
Search space by length and character set
When you are deciding which classes to enforce, this table shows how many possible passwords each character set and length combination produces. Against offline hash cracking, adding one character to the length almost always beats forcing one more character class.
| Character set | Set size | 8 chars | 12 chars |
|---|---|---|---|
Digits only 0-9 | 10 | 108 | 1012 |
Lowercase only a-z | 26 | ~2.1×1011 | ~9.5×1016 |
Mixed alphanumeric A-Za-z0-9 | 62 | ~2.2×1014 | ~3.2×1021 |
| Alphanumeric + symbols | ~95 | ~6.6×1015 | ~5.4×1023 |
Notice that 12 lowercase characters (~9.5×1016) has a larger search space than 8 characters that enforce all four classes (~6.6×1015). That is why this generator nudges you toward a minimum length of 12 or more rather than piling on class requirements.
Worked example: 12 chars with uppercase and digit required
Set the minimum length to 12, require uppercase and digits, and leave lowercase and symbols off. The generated regex looks like this:
^(?=.*[A-Z])(?=.*\d).{12,}$(?=.*[A-Z])— assert at least one uppercase letter exists anywhere (a lookahead, it consumes no position).(?=.*\d)— assert at least one digit exists..{12,}— assert the whole string is 12 characters or longer.
Spring2026Login passes (uppercase S, the digits 2026, 15 chars long), whilespring2026 fails on two counts: it has no uppercase letter and is only 10 characters. Because the symbol class is off, a password with no symbols still passes.
Common pitfall
- In the regex,
.matches any character except a newline. If a user accidentally includes leading or trailing spaces,.counts those spaces toward the length. On the server, hash the password as-is rather than silently trimming, but warn users about stray spaces introduced by copy-paste. - A lookahead like
(?=.*[A-Z])only checks presence and consumes no characters. If you instead chain class requirements inline as[A-Z].*\d, you impose an unintended ordering constraint (“an uppercase letter before a digit”). Always list independent lookaheads.
Frequently asked questions
Is the generated policy or regex sent to a server?
Is the output regex enough to validate passwords?
Why does maximum age default to no forced change?
How does the regex handle special characters?
What minimum length should I choose?
Related guides
- WordPress Security Basics: 10 Checks That Stop Most HacksThe common ways WordPress gets hacked, and the login, plugin, file-permission and header settings that stop them.