Password Requirements Checklist — Live Rules UI
Password Requirements Checklist · Forms · Plain HTML, CSS & JS · Live preview
What's included
Features
About this UI Snippet
Password Requirements Checklist — Real-Time Rule Validation with Strength Meter

Telling a user their password is "invalid" only after they hit submit is one of the most frustrating patterns in sign-up forms. A live requirements checklist fixes it by showing every rule up front and ticking each one off the instant it's satisfied, so the user always knows exactly what's left. This snippet builds that real-time validation in plain HTML, CSS, and vanilla JavaScript, paired with a strength meter and a show/hide toggle — the complete modern password field.
Every rule, checked on every keystroke
The requirements live in a RULES array, each with a label and a test function — at least 8 characters, an uppercase letter, a lowercase letter, a number, and a special character. On every input event, evaluate() runs all the tests and toggles a .met class on the matching list item, which flips its icon from an empty gray circle to a green checkmark and turns the text green. The user watches the list complete itself as they type, which is far less frustrating than discovering one missed rule at submit time. Adding or changing a rule is a one-line data edit — the list renders from the array.
A strength meter that reflects real coverage
Above the list, a four-segment bar shows password strength derived from how many rules pass: weak (red) when only one or two are met, up through strong (green) when all are satisfied. Crucially, the meter and the checklist agree because both read the same rule results — the bar can't say "strong" while a rule is still unchecked. The label ("Weak / Fair / Good / Strong") and the bar fill share one tier value, so they always move together.
Submit gated on every rule
The "Create account" button stays disabled until *all* rules pass, giving the user a clear finish line and preventing a doomed submit. This is the honest version of password validation: the form tells you what it wants, shows your progress, and only lets you proceed when you've actually met the policy — no surprise server-side rejection.
Show/hide toggle, done right
An eye button toggles the input's type between password and text and swaps the icon between "eye" and "eye-off", so users can verify what they typed — which research consistently shows reduces errors and abandonment more than it risks shoulder-surfing on a personal device. The toggle is a real button with an aria-label, not a click target bolted onto an icon.
Strength meter vs. checklist — why both
A strength meter alone is vague ("why is it only 'fair'?"), and a checklist alone doesn't convey overall quality at a glance. Together they cover both: the checklist tells the user *exactly* what to fix, while the meter gives an at-a-glance sense of how strong the result is. For a production system you'd also want to reject common/breached passwords (a strength meter can pass "Password1!" which is in every breach list) — the FAQs cover layering a library like zxcvbn or a breached-password check on top of these structural rules.
Accessible and portable
The checklist is a real <ul>, the rules read as plain text, and the whole component is driven by one evaluate() function with no framework dependency — so it ports cleanly to React, Vue, or Angular by moving the rule evaluation into reactive state.
Build with AI
Build, Understand, Optimize, and Extend It With AI
You don't need to trace every rule and tier calculation yourself. Paste this snippet's HTML, CSS, and JS into an AI coding assistant like Claude and ask it to explain exactly how the RULES array's test functions drive both the checklist and the four-tier strength bar off the same passed count, and why gating the submit button on passed !== RULES.length is safer than gating it on the strength tier alone. The same assistant can help optimize it, for example checking whether recomputing all five regex tests on every keystroke matters for performance on very long inputs, or whether the tier thresholds (passed <= 2, === 3, === 4) actually map to a sensible strength curve. It's also useful for extending the effect: ask it to add a minimum-length-of-12 rule, a "must not match a common password list" check, or a debounced async call to a breached-password API layered on top of the existing rules. Treat the code less like a finished artifact and more like a starting point for a conversation.
Prompt to recreate it
Copy this into your AI assistant of choice to build the effect from scratch, or as a jumping-off point for your own variant:
Build a live password requirements checklist in plain HTML, CSS, and vanilla JavaScript, driven entirely by a data array of rules rather than hardcoded conditionals.
Requirements:
- A password input paired with a show/hide eye toggle button that swaps the input's type between password and text and swaps the icon accordingly, without ever submitting the enclosing form.
- A RULES array where each entry has a label string and a test function taking the current input value and returning true or false; render the checklist by mapping over this array so adding, removing, or editing a rule requires no other code changes. Include at minimum: length of at least 8, one uppercase letter, one lowercase letter, one number, and one special character.
- On every input event, re-run every rule's test function, toggle a "met" class on each corresponding list item (which must visually flip an icon from an empty circle to a filled checkmark), and count how many rules currently pass.
- Derive a four-segment strength bar and a text label (Weak/Fair/Good/Strong) purely from the count of currently-passing rules, using the exact same per-keystroke results the checklist uses, so the bar and the checklist can never disagree with each other.
- Keep a submit button disabled at all times except when every single rule in the RULES array passes — not just when the strength bar reaches its highest tier.
- Ensure the whole thing is driven by one evaluate function with no external dependencies, so it can be ported into a reactive framework by moving just that function's logic into state.Want to tighten it up first? Run this prompt through the AI Prompt Studio to score it across 8 quality dimensions, catch anti-patterns, and tune the wording for Claude, ChatGPT, or Gemini before you paste it in.
Step by step
How to Use
- 1Paste HTML, CSS, and JSA password field renders with five unchecked requirements, a strength meter, and a disabled "Create account" button.
- 2Start typingEach requirement ticks green the moment it's satisfied, and the strength bar fills from red toward green as more rules pass.
- 3Watch the gateThe submit button stays disabled until every requirement is met, then enables — a clear finish line.
- 4Toggle visibilityClick the eye icon to reveal the password as plain text and verify what you typed; click again to hide it.
- 5Edit the rulesAdd, remove, or change entries in the RULES array (label + test function) — the checklist and gating update automatically.
- 6Add breached-password checksLayer a library like zxcvbn or a Have I Been Pwned check on top of these structural rules for real-world strength.
Real-world uses
Common Use Cases
Got questions?
Frequently Asked Questions
Edit the RULES array — each entry has a label and a test(value) function returning true when satisfied. Add a minimum length of 12, a "no spaces" rule, or a "not your email" check by adding entries; the checklist renders from the array and the submit gate requires all of them, so no other code changes.
No — structural rules (length, character classes) can pass weak, common passwords like "Password1!" that appear in every breach list. For real strength, layer a library like zxcvbn (which scores against common patterns and dictionary words) or check the password against a breached-password API such as Have I Been Pwned's k-anonymity endpoint, and treat those as additional gates.
Showing the rules up front (rather than only erroring after submit) lets users compose a valid password on the first try instead of guessing and retrying. Real-time ticking turns an opaque policy into visible progress, which measurably reduces sign-up friction and abandonment.
Gate submission on the checklist (every required rule met), not the strength meter — the meter is a guide, but "submit only when all rules pass" is the enforceable policy. The meter communicates overall quality at a glance; the checklist communicates the exact, must-pass requirements.
In React, hold the password in useState and derive each rule's met state and the overall validity with useMemo, rendering the list and disabling submit from that; in Vue, use ref()/computed(); in Angular, use a reactive form with custom validators per rule. The RULES array and test functions port unchanged — only the per-keystroke evaluation moves into reactive state.