Question 1

What is a password policy and why build one visually?

Accepted Answer

A password policy is a set of composition rules — minimum length, required character classes, minimum counts per class — that a candidate password must satisfy before it's accepted. Writing the equivalent validation regex by hand, with correct lookahead assertions and escaped character classes, is easy to get subtly wrong. A visual builder lets you set the rules once and generates a correct JSON schema, regex, and human-readable text from the same configuration.

Question 2

Does NIST still recommend strict character composition rules?

Accepted Answer

NIST SP 800-63B de-emphasizes forced composition rules in favor of length and screening new passwords against known-breached password lists. That said, many compliance frameworks — PCI-DSS, internal enterprise policies, some legacy systems — still require explicit character-class rules, which is exactly what this tool models. Use the length-only fields if you're following current NIST guidance, or add class requirements if a framework or system you integrate with demands them.

Question 3

How do I use the generated regex?

Accepted Answer

The regex combines a lookahead assertion per required character class — e.g. `(?=(?:.*[A-Z]){1,})` for at least one uppercase letter — with a final `.{min,max}` length check. Run it with `new RegExp(pattern).test(password)`; a `true` result means the password satisfies every active rule. It also works directly in an HTML `<input pattern="…">` attribute in modern browsers, and drops in as the source pattern for most schema-validation libraries.

Question 4

Why doesn't the JSON output include a maxLength field?

Accepted Answer

The `maxLength` key only appears in the JSON when you enable "Set a maximum length." Leaving it off by default is intentional — an unbounded maximum, subject to your backend's own hard limit, matches current NIST-aligned guidance to never truncate or over-restrict password length, since longer passwords are strictly better for entropy and cost an attacker exponentially more time to crack.

Question 5

Is it safe to test a real password in this tool?

Accepted Answer

Yes. The tester runs in JavaScript in your browser tab only — no network request is made, and nothing is logged or stored. Still, as a general habit, prefer a throwaway or representative test string over a password you actually use, the same way you would with any client-side tool.

Question 6

What counts as a "symbol" in the symbol requirement?

Accepted Answer

By default the symbol charset covers the common ASCII punctuation range: `!@#$%^&*()_+-=[]{};':"|,.<>/?~`. You can edit this field directly — the regex, JSON schema, and live tester all update together to match — which is useful if a target system, framework, or legacy backend only accepts a narrower set of special characters than the full default range.

Question 7

Can I enforce this policy on both the frontend and backend?

Accepted Answer

Yes — that's the point of generating all three formats from one configuration. Use the regex for an HTML `pattern` attribute or a schema-validation library on the frontend, the same regex (or the JSON fields) to re-validate on the backend, and the plain-English rules text as the requirements copy shown to users. Always re-validate server-side; client-side checks are a UX convenience, not a security boundary.

Password Policy Builder

Policy Rules

Test a Password

Export Policy

Why Use This Password Policy Builder?

How to Use the Policy Builder

Frequently Asked Questions