Password Strength

Demo & usage

More examples

<sv-input-field label="Password" type="password" [(value)]="password" />
<sv-password-strength [value]="password()" />

<sv-password-strength [value]="password()" size="sm" [showSuggestions]="false" />

<!-- Length is counted from here; variety only pays out once it is met. -->
<sv-password-strength [value]="password()" [minLength]="14" />

<!-- breach is an input, never a request from the component. Check on blur or
     on submit — never per keystroke, which sends every prefix of someone's
     password to a third party. Map both a non-OK response and a thrown error
     onto 'unavailable': an outage is not a clean bill of health. -->
<sv-password-strength
  [value]="password()"
  [breach]="breach()"
  (guidanceChange)="guidance.set($event)" />

When to use

• Sign-up, invite-acceptance and password-change forms where you want to explain what would make a password harder to guess.
• Anywhere you want live client-side advice without shipping a large dictionary-backed scoring library.
• To surface a breach-list result you already have — pass it in as `breach` and let the component word it, including the outage case.
• Not a security boundary and not a gate. Enforce your policy in the field validator and on the server; this component explains.

Async states

None — this component has nothing to load, so it has no loading, empty or error state to drive.

Outputs

Customization & theming

• Two densities: `md` (default) and `sm`.
• `showSuggestions` toggles the suggestion list independently of the bar and band label.
• `announceDelay` (default 700ms) is the quiet period before a band change is announced; every keystroke restarts it.
• The headless `evaluatePassword()` function and the `PASSWORD_STRENGTH_LABELS` map are exported separately from `@styloviz/password-strength` for custom UI or server-side reuse of the same heuristic.

Best practices

• Do: Bind `value` to the exact same signal driving your password field, so the meter always reflects what was actually typed.
• Do: Pass a `minLength` that matches your actual password policy (default 12) — the length points and the "use at least N characters" suggestion both key off it.
• Do: Own the breach lookup yourself and pass the answer in via `breach`. Map a non-OK response *and* a thrown error onto `unavailable` — reading an outage as `safe` claims a check that never happened, and reading it as `breached` locks people out of their own sign-up.
• Don't: Don't gate submission on the band. `guidanceChange` is advice, not a verdict — `[disabled]="guidance()?.band < 2"` turns a browser-side guess into a rule and rejects passwords that are perfectly good.
• Don't: Don't layer composition rules ("one uppercase, one digit, one symbol") on top of this. They produce `Password1!` — the weakest string that satisfies every rule — which is why length carries three of the four points here and NIST SP 800-63B recommends against them.
• Tip: Store `fromBreachCheck` alongside the band if you log anything: band 0 means "short and predictable" in one case and "this exact string is in a breach corpus" in the other, and only the second is evidence.

Accessibility

• The visible band label is plain text, deliberately not a live region — as `role="status"` it re-announced on every keystroke and interrupted screen-reader users mid-word, which made the field unusable.
• A separate `sr-only` `aria-live="polite"` region carries the same words, and speaks only when the band actually changes and only after typing has paused for `announceDelay`.
• The segmented bar is `aria-hidden` — the band label carries the same information in words, so the bar never needs its own name.
• A breach notice is polite text, never an alert, and an in-flight check is marked `aria-busy` rather than reporting an answer it does not have.
• Suggestions render as a real list (`<ul>`/`<li>`), readable by assistive tech in document order.