UX Patterns Guide
Back to compare picker

Password creation vs Password input vs Inline validation vs Error summary

Prefer password creation when the task is account registration, password reset, first-time setup, or changing a password to a new reusable secret.

Password creation live examplePassword input live exampleInline validation live exampleError summary live example

Decision dimensions

Dimension Password creationPassword inputInline validationError summary
UI or UX UI + UX - New authentication secret selection flowUI + UX - Authentication secret entry controlUI + UX - Field-level validation feedbackUI + UX - Form recovery summary
UI guidance Render password creation as a labelled new-password field with visible policy guidance, generator and paste compatibility, show and hide control, field-level rejection reasons, and a confirmation state that never displays the accepted secret later.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.Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance Use password creation when a user is choosing a new reusable secret during registration, password reset, first-time setup, or password change.Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.Help users correct a specific field without losing or re-entering the value they already typed.Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI A signup form labels the field New password, uses autocomplete new-password, allows password-manager generation, says Use at least 15 characters or a generated password, and rejects Password123 because it is commonly used.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.Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI A form requires one uppercase letter, one lowercase letter, one number, one symbol, no spaces, and a 12-character maximum while still accepting Summer2026!A login form uses a normal text field named Password and leaves the secret visible on screen.Only a red border with no message.Red banner saying fix errors with no links.
Good UX A user accepts a password-manager suggestion, pastes it into the field, sees that it meets length and is not in the blocked list, and continues without retyping it.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.Validation appears after blur or submit when it helps correction.After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX A user enters a strong generated password but the site silently cuts it at 16 characters, so the saved password does not match the password manager.A user cannot paste from a password manager and shortens the password to something easier to type.Showing errors before users type.Only showing errors below the fold.
Best fit The user is creating an account with a reusable password.The user needs to enter an existing password, passphrase, or PIN-like memorized secret.A single field has a specific correctable problem.Form submission can produce one or more errors.
Avoid when The user is only entering an existing password to sign in or reauthenticate.The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.The main recovery task is finding several errors across a submitted page.A single local field issue can be corrected before submit without page-level orientation.
Required state Initial new-password state with purpose, autocomplete new-password, minimum length, paste support, show and hide control, and no character-class checklist.Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.Neutral field with label, hint, and no error.Neutral form before submit with no summary.
Accessibility burden Use a visible label that says New password or Create a password rather than only Password when the user is choosing a new value.Use a visible label that names the password purpose, such as Password or Current password.Expose invalid state on the input and connect error text to the field description where possible.Use a heading and alert behavior that makes the summary discoverable.
Common misuse Using uppercase, lowercase, number, and symbol checklists as the main security signal.Using type text for passwords.Showing field errors before users have interacted with the control.Showing a red banner or toast with no links to the invalid answers.

Password creation

UI or UX
UI + UX - New authentication secret selection flow
UI guidance
Render password creation as a labelled new-password field with visible policy guidance, generator and paste compatibility, show and hide control, field-level rejection reasons, and a confirmation state that never displays the accepted secret later.
UX guidance
Use password creation when a user is choosing a new reusable secret during registration, password reset, first-time setup, or password change.
Good UI
A signup form labels the field New password, uses autocomplete new-password, allows password-manager generation, says Use at least 15 characters or a generated password, and rejects Password123 because it is commonly used.
Bad UI
A form requires one uppercase letter, one lowercase letter, one number, one symbol, no spaces, and a 12-character maximum while still accepting Summer2026!
Good UX
A user accepts a password-manager suggestion, pastes it into the field, sees that it meets length and is not in the blocked list, and continues without retyping it.
Bad UX
A user enters a strong generated password but the site silently cuts it at 16 characters, so the saved password does not match the password manager.
Best fit
The user is creating an account with a reusable password.
Avoid when
The user is only entering an existing password to sign in or reauthenticate.
Required state
Initial new-password state with purpose, autocomplete new-password, minimum length, paste support, show and hide control, and no character-class checklist.
Accessibility burden
Use a visible label that says New password or Create a password rather than only Password when the user is choosing a new value.
Common misuse
Using uppercase, lowercase, number, and symbol checklists as the main security signal.

Password input

UI or UX
UI + UX - Authentication secret entry control
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.
UX guidance
Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.
Good UI
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.
Bad UI
A login form uses a normal text field named Password and leaves the secret visible on screen.
Good UX
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.
Bad UX
A user cannot paste from a password manager and shortens the password to something easier to type.
Best fit
The user needs to enter an existing password, passphrase, or PIN-like memorized secret.
Avoid when
The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.
Required state
Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.
Accessibility burden
Use a visible label that names the password purpose, such as Password or Current password.
Common misuse
Using type text for passwords.

Inline validation

UI or UX
UI + UX - Field-level validation feedback
UI guidance
Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance
Help users correct a specific field without losing or re-entering the value they already typed.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Only a red border with no message.
Good UX
Validation appears after blur or submit when it helps correction.
Bad UX
Showing errors before users type.
Best fit
A single field has a specific correctable problem.
Avoid when
The main recovery task is finding several errors across a submitted page.
Required state
Neutral field with label, hint, and no error.
Accessibility burden
Expose invalid state on the input and connect error text to the field description where possible.
Common misuse
Showing field errors before users have interacted with the control.

Error summary

UI or UX
UI + UX - Form recovery summary
UI guidance
Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance
Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Red banner saying fix errors with no links.
Good UX
After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX
Only showing errors below the fold.
Best fit
Form submission can produce one or more errors.
Avoid when
A single local field issue can be corrected before submit without page-level orientation.
Required state
Neutral form before submit with no summary.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Showing a red banner or toast with no links to the invalid answers.
Decision rules
  • Prefer password creation when the task is account registration, password reset, first-time setup, or changing a password to a new reusable secret.
  • Prefer password input when the user is entering an existing password for sign-in, reauthentication, or current-password confirmation; do not show new-password strength guidance on every sign-in field.
  • Prefer inline validation inside password creation for correctable field-level guidance such as too short, commonly used, breached, contains the service name, or does not match an already stated restriction.
  • Prefer error summary when the user submits account creation or password reset with multiple problems and needs a top-of-form list that links back to the password field.
  • Use autocomplete new-password for new or changed passwords, current-password for the current password field in a change flow, and keep account identifier autocomplete separate.
  • Help users create strong and unique passwords by supporting password managers and generated passwords, accepting paste, allowing long values, and avoiding arbitrary composition rules.
  • Use minimum length, breached-password or common-password checks, and service-specific banned terms instead of requiring mixtures of uppercase, lowercase, number, and symbol characters.
  • If a chosen password is rejected, explain the reason enough for correction without revealing the full banned list or encouraging trivial substitutions.
  • Do not require periodic changes or password reminders; use reset links or codes, compromise-driven rotation, MFA, or passwordless routes for stronger account protection.
  • Do not show the new password on review pages, logs, analytics, support tools, receipts, or account summaries; creation owns selection and safe acceptance, not later display.
Inspect live examples
Password creationPassword inputInline validationError summary
Failure modes
  • A signup form requires uppercase, lowercase, number, symbol, no spaces, and a short maximum, causing users to make predictable variations.
  • A form blocks password-manager paste or generated passwords, so users choose a weaker secret they can type manually.
  • A weak password such as Password123 is accepted because the form only checks character classes.
  • A strength meter says Strong for a service-name variation that appears on a banned-password list.
  • A password reset flow sends the new password by email or asks for a reminder question.
  • An error summary says only Invalid password and gives no route back to the rejected field or reason.