Password input vs Text input vs Inline validation vs Error summary

Prefer password input when the value is a secret used for authentication, reauthentication, unlocking a protected action, confirming account ownership, or entering a PIN-like memorized secret.

Password input live example Text input live example Inline validation live example Error summary live example

Decision dimensions

Dimension	Password input	Text input	Inline validation	Error summary
UI or UX	UI + UX - Authentication secret entry control	UI + UX - Single-line freeform data-entry control	UI + UX - Field-level validation feedback	UI + UX - Form recovery summary
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.	Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.	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 input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.	Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.	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 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 reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.	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 login form uses a normal text field named Password and leaves the secret visible on screen.	The only instruction is placeholder text that disappears when the user starts typing.	Only a red border with no message.	Red banner saying fix errors with no links.
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.	A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.	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 cannot paste from a password manager and shortens the password to something easier to type.	Validation fires on the first focus event and blocks typing before the user has had a chance to answer.	Showing errors before users type.	Only showing errors below the fold.
Best fit	The user needs to enter an existing password, passphrase, or PIN-like memorized secret.	The answer is short and user-authored.	A single field has a specific correctable problem.	Form submission can produce one or more errors.
Avoid when	The value is not a secret, such as a name, email address, account number, search query, reference, or ordinary note.	The answer is a paragraph, comment, address block, or explanation requiring multiple lines.	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 hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.	Empty untouched state with persistent label and optional hint.	Neutral field with label, hint, and no error.	Neutral form before submit with no summary.
Accessibility burden	Use a visible label that names the password purpose, such as Password or Current password.	Associate every text input with a visible label or equivalent accessible name that matches the visible question.	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 type text for passwords.	Using placeholder text as the only label or instruction.	Showing field errors before users have interacted with the control.	Showing a red banner or toast with no links to the invalid answers.

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.

Text input

UI or UX: UI + UX - Single-line freeform data-entry control
UI guidance: Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance: Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
Good UI: A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI: The only instruction is placeholder text that disappears when the user starts typing.
Good UX: A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX: Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit: The answer is short and user-authored.
Avoid when: The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state: Empty untouched state with persistent label and optional hint.
Accessibility burden: Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse: Using placeholder text as the only label or instruction.

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 input when the value is a secret used for authentication, reauthentication, unlocking a protected action, confirming account ownership, or entering a PIN-like memorized secret.
Prefer text input when the value is meant to remain visible, searchable, copied into review pages, or stored as ordinary profile or form text; do not obscure ordinary names, emails, references, or account labels as passwords.
Prefer inline validation to explain missing password, disabled password-manager support, Caps Lock warning, or field-level entry problems next to the password field, but do not reveal whether the username or password was the wrong credential after a failed login.
Prefer error summary when a sign-in or account form has multiple fields and the user needs a keyboard-reachable summary that links to the password or username field after submit.
Use current-password autocomplete for existing sign-in passwords, new-password for creating or changing a password, and one-time-code for short-lived codes rather than treating every secret field alike.
Hide password text by default, provide a user-controlled show and hide action, and return the field to password type before submit if it was visible.
Allow paste, autofill, and password managers; blocking paste or disabling manager features makes strong generated passwords harder to use.
Disable spellcheck and automatic capitalization so visible password text is not modified or sent through spelling tools.
Clear the password value after a failed login attempt and show a combined account-details error instead of revealing whether the password alone was wrong.
Do not use a password field as a formatting mask, secret note field, account recovery substitute, or review-before-submit value; password entry owns secret capture and should not display the secret later.

Inspect live examples

Password input Text input Inline validation Error summary

Failure modes

A login form uses a normal text input, so the password remains visible in the room and may be saved as ordinary form text.
A form blocks paste, preventing password-manager use and encouraging weaker typed passwords.
A failed sign-in message says the password was wrong, helping attackers enumerate valid usernames.
The password remains visible after submit, browser Back, or failed authentication.
Spellcheck or autocapitalization changes the entered secret or exposes it to third-party tooling.
A page uses inline validation to reject password characters that existing users already have in valid stored passwords.

Sources

GOV.UK Design System Password input
GOV.UK supports type password, show and hide controls, current-password autocomplete, paste support, spellcheck and autocapitalization controls, no confirm field, and combined account-details errors.
NIST SP 800-63B Passwords
NIST supports password-manager and autofill use, paste support, display option, minimum and maximum length expectations, acceptance of printable characters, no composition rules, protected channels, rate limits, and salted hashing.
MDN input type password
MDN supports password input semantics, obscured content, current-password and new-password autocomplete, required and length attributes, PIN input modes, and normal text-editing behavior.
MDN HTML autocomplete password tokens
MDN supports current-password, new-password, and one-time-code autocomplete distinctions.
OWASP Authentication Cheat Sheet password manager guidance
OWASP supports standard HTML password forms, password-manager compatibility, paste support, printable characters, reasonable maximum length, and simple Tab navigation.

Verification

Last verified: 2026-06-09