Password Policy Tester

Build a password policy and test real examples against it, so you find the contradictory rules that block good passwords before your users do.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Start from

Minimum length

Maximum length (0 for none)

Minimum character classes (0 to ignore)

Require An uppercase letter A lowercase letter A digit A symbol

Block Known common passwords Repeated sequences Sequences and keyboard runs Allow spaces (passphrases)

Your own examples, one per line Tested locally, alongside the built-in examples.

The interesting question is what your policy rejects

Anyone can confirm a policy blocks password1. That is not where policies go wrong.

They go wrong at both ends simultaneously. Composition rules measure the shape of a password rather than how hard it is to guess, so they cheerfully accept Password1! - which satisfies every rule and is one of the most-guessed passwords in existence - while rejecting correct horse battery staple, which has four times the entropy but no digit.

So every example here is scored twice: does the policy accept it, and is it actually strong. Where the two disagree, that is the headline. A policy with false accepts is letting weak passwords through; a policy with false rejects is pushing users towards something worse, because a person forced to abandon a passphrase they could remember writes down whatever they invent instead.

Specific rules that do damage

A low maximum length. Passwords are hashed to a fixed size, so length costs nothing to store. A 16-character limit usually means the password is going somewhere it should not - a column sized for plaintext, or a legacy system that never hashed anything.
Disallowing spaces. This blocks passphrases outright, which are the easiest route to a strong password somebody can actually remember. There is no security argument for it.
Requiring all four character classes. People satisfy this in the most predictable way available: capitalise the first letter, add 1, add !. Cracking tools generate that shape directly. The rule made the password predictable.
Forced periodic rotation - not testable here, but worth stating. It reliably produces Summer2024! becoming Autumn2024!, and NIST now recommends against it except on evidence of compromise.

The one rule that works

Check the candidate against a list of known-breached passwords and reject matches. It is the rule NIST SP 800-63B actually recommends, and it targets what attackers actually try rather than what passwords look like. Combined with a decent minimum length, it outperforms every composition rule put together.

The check here uses a few hundred of the most common passwords. A real implementation should use a proper corpus - Have I Been Pwned's range API lets you check without sending the password, by submitting the first five characters of its SHA-1 hash and comparing locally.

Tested in your browser

The built-in examples and anything you add are evaluated locally. Nothing is transmitted.

Frequently asked questions

My policy shows no disagreements. Is it good?

It agrees with the strength engine on these examples, which is a good sign rather than a guarantee. Add your own examples - especially real ones your users have complained about - to test it where it matters.

Why does the NIST preset require so little?

Because SP 800-63B concluded that composition rules cause more harm than good. It asks for length, a check against breached passwords, and no arbitrary maximum - and drops the rest. It looks permissive and is measurably stronger.

Our compliance framework demands complexity rules.

Many still do, and this page will not resolve that. What it can do is show you the cost: which strong passwords your rules reject and which weak ones they wave through. That is a more useful conversation than arguing from principle.

Is the strength score here the same as the entropy calculator?

Yes, the same engine. It reports a realistic guessing estimate rather than character-set entropy, which is why Password1! scores badly despite using four character classes.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.