Password Requirements Checklist — Live Rules UI

Password Requirements Checklist · Forms · Plain HTML, CSS & JS · Live preview

Share & Support

What's included

Features

Live per-rule validation
Each requirement ticks off the instant it's satisfied, so users always know exactly what's left to fix.
Data-driven rule list
Rules are an array of label + test functions — add, remove, or reorder them with a one-line edit.
Strength meter that agrees with the list
A four-segment bar derives its tier from the same rule results, so it can never contradict the checklist.
Submit gated on all rules
The button enables only when every requirement passes, preventing a doomed submit and surprise rejection.
Show/hide password toggle
An accessible eye button swaps the input type and icon so users can verify what they typed.
Color-coded progress
Met rules turn green with a checkmark; the strength label and bar share one weak→strong color scale.
Animated check transitions
Each rule's icon fades from an empty circle to a green checkmark, giving satisfying real-time feedback.
Framework-agnostic core
One evaluate() function drives everything, porting cleanly to React, Vue, or Angular reactive state.

About this UI Snippet

Password Requirements Checklist — Real-Time Rule Validation with Strength Meter

Screenshot of the Password Requirements Checklist snippet rendered live

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:

text
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

  1. 1
    Paste HTML, CSS, and JSA password field renders with five unchecked requirements, a strength meter, and a disabled "Create account" button.
  2. 2
    Start typingEach requirement ticks green the moment it's satisfied, and the strength bar fills from red toward green as more rules pass.
  3. 3
    Watch the gateThe submit button stays disabled until every requirement is met, then enables — a clear finish line.
  4. 4
    Toggle visibilityClick the eye icon to reveal the password as plain text and verify what you typed; click again to hide it.
  5. 5
    Edit the rulesAdd, remove, or change entries in the RULES array (label + test function) — the checklist and gating update automatically.
  6. 6
    Add 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

Sign-up and registration forms
The standard new-password field that shows its policy up front — pair with a conditional form fields flow for the rest of signup.
Password reset and change
Reuse the same checklist when users set a new password, with an optional "must differ from current" rule.
Account security settings
Show requirements when a user strengthens their password from settings, pairing with a password generator option.
Admin and team onboarding
Enforce an organization's password policy visibly during member invitation acceptance.
Compliance-driven products
Make a required complexity policy explicit and auditable for regulated industries.
Learning real-time validation
A reference for per-rule live feedback and gated submission — compare with a password strength meter for the score-only approach.

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.