Use password input when a user must enter an existing secret or PIN-like memorized secret; use text input for non-secret text, inline validation for field-level correction, and error summary for reachable form-level recovery.
Use password input when a user must enter an existing secret or PIN-like memorized secret; use text input for non-secret text, inline validation for field-level correction, and error summary for reachable form-level recovery.
Practice the judgment: Imagine this situation: A login form uses a normal text input, so the password remains visible in the room and may be saved as ordinary form text. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| 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. | Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text. | Help the person reach a clear task outcome. | Move users from the summary to the exact field, group, or first invalid control that needs correction. |
| Good UI | 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 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. | Error message appears far from the field it describes. | Summary and field messages visually disconnected or contradictory. |
| Good UX | The person reaches the intended result with clear feedback. | A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error. | 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 failed login page says the password is wrong, confirming that the username exists. | 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 task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection. | 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. | The message is a system failure, permission problem, or outage rather than a validation issue. |
| 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. | Invalid field with preserved user value and adjacent correction text. | Failed-submit state with summary visible near the form heading. |
| 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. | Replacing field-level messages with only a top-level summary. |