Password Strength UI

Practical patterns for password requirements users can understand before they submit.

01 — Foundation

Strength UI guides — it does not gatekeep with theatre

Users need to know requirements before submit, not only after a red bar shames them.

Password strength indicators help users meet policy without guesswork. Poor implementations rely on colour alone, block paste, or show meaningless “weak/strong” meters with no actionable rules.

02 — Requirements

Show rules up front

List what the password must satisfy — check off met rules as the user types.

  • plain language — “At least 12 characters”, “One number” — not regex hieroglyphics; same clarity as GOV.UK error messages
  • mark met requirements with text and icon — not colour alone
  • show confirm-password field when needed; link errors to both fields — see accessible forms
  • allow paste and password managers — never disable them for “security theatre”

03 — Meter

Meters and announcements

A progress bar is optional; clarity is mandatory.

  • if you show a meter, tie it to explained rules — not arbitrary gradients
  • do not announce strength on every keystroke — batch or use visible list state
  • use type="password" with show/hide toggle that is keyboard accessible 
<label for="new-password">New password</label>
<input id="new-password" type="password" autocomplete="new-password" aria-describedby="password-rules" />
<ul id="password-rules">
    <li>At least 12 characters</li>
</ul>

04 — Review

Before you approve

A short checklist for password strength UI in code review.

  • requirements visible before failure; met rules are perceivable without colour alone
  • paste and managers work; show-password control is accessible
  • aligns with Account Recovery and Accessible Forms patterns