UX Patterns Guide
UI + UX Input And Data Entry standard

Password input

Use a proper password field that hides the secret by default, supports password managers and paste, offers controlled show and hide, avoids spellcheck and autocapitalization, handles errors without account enumeration, clears failed secrets, and submits through the protected authentication flow.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The user needs to enter an existing password, passphrase, or PIN-like memorized secret.
  • The flow is sign-in, reauthentication, account unlock, sensitive-action confirmation, or current-password confirmation.
  • The service can support password managers, paste, autofill, secure transport, rate limiting, and safe error handling.
  • The user may need to temporarily reveal the secret to correct typing.

Avoid when

  • The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.
  • The task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection.
  • The task is entering a one-time code, recovery code, passkey, magic link, or MFA challenge rather than a reusable memorized secret.
  • The product cannot prevent the raw secret from entering logs, analytics, local storage, support tools, or screenshots.
  • A passwordless or federated authentication route is the intended primary path and the password field would add unnecessary credential handling.

Problem it prevents

Passwords are secrets that users often enter under observation risk, through password managers, and in high-stakes authentication flows, so ordinary text entry, paste blocking, revealing errors, or weak visibility controls can expose credentials or block safe behavior.

Pattern anatomy

What a strong implementation has to make clear

User need

The user is signing in, reauthenticating before a sensitive action, confirming a current password before a change, entering a PIN-like memorized secret, or unlocking an account recovery step.

Pattern promise

Use a proper password field that hides the secret by default, supports password managers and paste, offers controlled show and hide, avoids spellcheck and autocapitalization, handles errors without account enumeration, clears failed secrets, and submits through the protected authentication flow.

Required state

Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.

Recovery path

A visible text field exposes the password to nearby people or screen recordings.

Access contract

Use a visible label that names the password purpose, such as Password or Current password.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A sign-in form has Email and Password fields, the password field uses autocomplete current-password, a Show button, no spellcheck, and an account-details error after failed login.
  • A reauthentication dialog asks for Current password, lets the user show it temporarily, accepts a pasted manager value, and clears the field after an incorrect attempt.
  • A user pastes a generated password from a password manager, toggles Show to inspect one character, hides it again, and signs in without the value appearing later in review or history.
  • A user mistypes credentials, receives Check your email address and password, and the password field is cleared so the secret is not left visible or reusable by another person.
Weak implementation

Vague, hidden, hard to recover from

  • A login form uses a normal text field named Password and leaves the secret visible on screen.
  • A page disables paste, adds a custom keyboard trap, and says Password incorrect while keeping the typed password visible.
  • A user cannot paste from a password manager and shortens the password to something easier to type.
  • A failed login page says the password is wrong, confirming that the username exists.
UI guidance
  • Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input.
  • When a password becomes visible, label the state clearly, announce the visibility change where needed, and return the field to password type before submission or after a failed authentication.
UX guidance
  • Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.
  • Support password managers, paste, autofill, long values, and printable characters, while handling failed login attempts without revealing whether the password alone was wrong.
Implementation contract

What the implementation must handle

States

  • Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.
  • Focused hidden state that preserves native text editing and password-manager affordances.
  • Visible state after the user chooses Show, with matching Hide control and visibility announcement.
  • Pasted password-manager value state with the value accepted and not truncated.

Interaction

  • Typing, paste, selection, deletion, undo, and password-manager autofill work through native input behavior.
  • The Show action changes only visibility, not the password value, cursor position, autocomplete purpose, or validation state.
  • The Hide action obscures the secret immediately and updates the control label.
  • Submitting while visible changes the field back to password type before the request leaves the page.

Accessibility

  • Use a visible label that names the password purpose, such as Password or Current password.
  • Associate hint, Caps Lock warning, and error text with the input.
  • Expose the Show and Hide control as a button with state-specific accessible labels and avoid relying only on an icon.
  • Announce visibility changes without reading the password value.

Review

  • Is this value truly an authentication secret, or is it ordinary text being hidden?
  • Does the field use current-password, new-password, or one-time-code according to the task?
  • Can a user paste or autofill from a password manager without losing characters?
  • What happens to the password value after failed login, browser Back, session timeout, and visible submit?
Interactive lab

Inspect the states before you copy the pattern

Enter an existing password safely

Paste from a password manager, toggle show and hide, inspect Caps Lock and failed-login recovery, and confirm the form clears the secret without revealing which credential was wrong.

Password input
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.

Keyboard / Access

Tab order follows account identifier, password field, show or hide control, recovery link, and submit action.

Avoid Generating

Using type text for passwords.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Password input

GOV.UK Design System - checked

GOV.UK supports password type, show and hide controls, current-password autocomplete, paste support, failed-login clearing, combined account-detail errors, no confirm field, spellcheck disabled, and autocapitalization disabled.

NIST SP 800-63B Passwords

National Institute of Standards and Technology - checked

NIST supports password-manager and autofill use, paste support, display option, length expectations, no composition rules, protected channels, rate limits, and salted hashing.

MDN input type password

MDN Web Docs - checked

MDN supports password input semantics, obscured content, current-password and new-password autocomplete, PIN input mode, required fields, and normal text editing.

Full agent/debug reference

Problem Context

  • The user is signing in, reauthenticating before a sensitive action, confirming a current password before a change, entering a PIN-like memorized secret, or unlocking an account recovery step.
  • Users may rely on browser autofill, password managers, generated passwords, copy and paste, hardware keyboards, mobile keyboards, or screen readers.
  • The UI must balance shoulder-surfing risk with error recovery, especially when users need to inspect the value they typed.
  • Authentication failures can leak whether an account exists if the product reports the username and password parts separately.
  • Password entry connects to backend concerns such as protected transport, rate limiting, hashing, account lockout, recovery, MFA, and breach response even though the field itself only captures the secret.

Selection Rules

  • Choose password input when the value is a password, passphrase, PIN-like memorized secret, current password, reauthentication secret, or credential confirmation value.
  • Use autocomplete current-password for existing password entry, new-password for choosing or changing a password, and one-time-code for short-lived codes.
  • Hide password values by default and give users a clear show and hide control when the surrounding context allows it.
  • Use distinct show and hide labels when multiple password inputs are on one page.
  • Disable spellcheck and automatic capitalization for password fields, especially when the value can become visible.
  • Allow paste, autofill, and password managers; do not trap keyboard focus or require character-by-character typing.
  • Accept long passwords and printable characters unless a documented technical constraint exists, and explain any constraint consistently wherever users create or enter the password.
  • After failed sign-in, clear the password field and show a combined account-details message rather than saying the password alone is wrong.
  • Move focus to the password error or error summary after submit without leaving the secret visible.
  • Return the input type to password before submitting if the user had chosen to show it.
  • Do not use password input for non-secret identifiers, email addresses, account labels, security answers, one-time recovery codes, or masked formatting of ordinary text.
  • Do not show the password on review pages, receipts, logs, analytics, screenshots, or support tools.

Required States

  • Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.
  • Focused hidden state that preserves native text editing and password-manager affordances.
  • Visible state after the user chooses Show, with matching Hide control and visibility announcement.
  • Pasted password-manager value state with the value accepted and not truncated.
  • Caps Lock or keyboard-warning state that helps the user without changing the secret.
  • Missing password error state connected to the field.
  • Failed sign-in state with combined email and password error, cleared password value, and recovery link.
  • Rate-limited or too many attempts state with next-step guidance and no secret disclosure.
  • Successful submit state where the field has returned to type password and the value is not shown in review.
  • Browser Back or session timeout state that does not restore a visible password.

Interaction Contract

  • Typing, paste, selection, deletion, undo, and password-manager autofill work through native input behavior.
  • The Show action changes only visibility, not the password value, cursor position, autocomplete purpose, or validation state.
  • The Hide action obscures the secret immediately and updates the control label.
  • Submitting while visible changes the field back to password type before the request leaves the page.
  • A failed authentication clears the password field and does not reveal which credential part was wrong.
  • Errors are reachable by keyboard and screen reader without reading the password value aloud.
  • The field never stores the raw password in local storage, visible review, analytics events, or reusable page state.

Implementation Checklist

  • Use a native input with type password, a visible label, autocomplete current-password for sign-in, spellcheck false, autocapitalize none or off, and aria-describedby for hints and errors.
  • Implement Show and Hide as a real button with aria-controls, state-specific accessible labels, and a polite announcement if the visibility change needs to be announced.
  • Allow paste, autofill, password-manager overlays, long values, spaces, and printable characters; do not use maxlength unless the user receives an explicit validation error instead of silent truncation.
  • Use a combined credential failure message, clear the password after failed authentication, keep recovery links visible, and handle rate limiting without leaking account existence.
  • Ensure the backend uses protected transport, rate limits attempts, and stores password verifiers as salted hashes with suitable work factors.
  • Test password managers, browser autofill, paste, mobile keyboards, Caps Lock, show/hide, failed login, browser Back, session timeout, zoom, screen readers, high contrast, and multiple password inputs on one page.

Common Generated-UI Mistakes

  • Using type text for passwords.
  • Blocking paste or password-manager autofill.
  • Leaving the password visible after submit, error, or browser Back.
  • Showing Password incorrect when the account identifier was valid.
  • Adding spellcheck or autocapitalization to a visible password field.
  • Using maxlength so pasted manager values are silently truncated.
  • Requiring confirm password for an existing-password sign-in field.
  • Displaying password values on review pages, logs, support screens, screenshots, or analytics events.
  • Using password input for ordinary masked identifiers or non-secret text.

Critique Questions

  • Is this value truly an authentication secret, or is it ordinary text being hidden?
  • Does the field use current-password, new-password, or one-time-code according to the task?
  • Can a user paste or autofill from a password manager without losing characters?
  • What happens to the password value after failed login, browser Back, session timeout, and visible submit?
  • Does the error message avoid revealing whether the account identifier or password was wrong?
  • Are spellcheck, autocapitalization, logs, analytics, screenshots, and support tools prevented from capturing the secret?
Accessibility
  • Use a visible label that names the password purpose, such as Password or Current password.
  • Associate hint, Caps Lock warning, and error text with the input.
  • Expose the Show and Hide control as a button with state-specific accessible labels and avoid relying only on an icon.
  • Announce visibility changes without reading the password value.
  • Keep password-manager overlays, browser affordances, and screen reader interactions compatible with the native input.
  • When multiple password inputs are present, make each toggle label unique.
  • Ensure the error summary links to the password field or account identifier field without exposing the secret.
Keyboard Behavior
  • Tab order follows account identifier, password field, show or hide control, recovery link, and submit action.
  • Typing, paste, selection, deletion, undo, redo, and password-manager autofill use native input behavior.
  • Space or Enter activates the show and hide button without submitting the form.
  • Submitting with an error moves focus to the error summary or first invalid field and clears failed password values when appropriate.
  • Escape is not required to hide the password, but if implemented it must not erase the value unexpectedly.
  • Browser Back does not restore a password in visible text.
Variants
  • Current password sign-in field
  • Reauthentication password field
  • PIN-like password field
  • Show and hide password
  • Password-manager autofill
  • Pasted generated password
  • Caps Lock warning
  • Combined credential error
  • Cleared failed password
  • Rate-limited sign-in

Verification

Last verified: