Should a customer password field have a show and hide control?

Start with the customer decision

A masked password field protects against someone glancing at a shared screen, yet masking makes a mistyped phrase hard to spot. A visible show control gives the customer a deliberate choice at the moment it is useful. Treat this as part of the sign-in and password creation journey, rather than as a decorative eye icon. Ask whether the customer can inspect what they entered, return to masking, and submit without losing the value. The GOV.UK Design System describes this choice for password inputs and recommends hiding by default. For a Hong Kong service, write the control and its help text in the active page language so its action remains clear in both editions.

Begin with a real task: a customer pastes a long password from a manager, receives an error, and wants to check whether an extra space was included. The control should let them inspect the field without opening a second screen or requiring a second copy of the password. A different customer may be on a crowded train and should be able to leave the value masked throughout. These two needs are compatible when visibility is optional and reversible. Do not use visibility as an excuse to demand manual typing, restrict pasted content, or remove the ordinary password field. Those changes would undermine the very reason the control exists.

Make the control an action, not a picture

Put a real button next to the password input and give it a name that says what will happen, such as Show password. When the value is visible, the next action should be Hide password. Use a button type that cannot submit the form accidentally. Keep the input's visible label as Password or a more precise equivalent, and associate the button with that input. A symbol may support recognition, but it should not be the only explanation. Test the English and Traditional Chinese names at the moment before and after activation. A translated label that describes the current state when users expect the next action can lead to the wrong click.

Preserve the field value and the customer's place while switching visibility. Replacing the whole input node can disturb selection, focus, autofill, validation and screen-reader context. The practical acceptance test is simple: place the caret in the middle of a sample password, show it, hide it, and check that the characters and editing position remain usable. Then repeat after a password manager fills the field and after the form reports an error. If the site uses more than one password input, each button must identify its own field; a generic Show label repeated twice leaves customers unsure which secret will become visible. GOV.UK explicitly calls for distinct labels when multiple password inputs appear.

Keep the underlying password flow intact

The underlying control remains a password input when the page first loads. Use the appropriate autocomplete purpose: current-password for sign-in and new-password when creating or changing a password. GOV.UK and W3C guidance both describe allowing browsers and password managers to recognize and fill well-labelled fields. Leave copy and paste available. Some customers rely on a standalone manager and transfer the value through the clipboard; blocking paste creates avoidable memory and transcription work. Show and hide should complement those mechanisms, not replace them. If scripting fails, a normal masked password field and form submission should still be intelligible whenever the service architecture permits it.

A visible password is still a secret. Make the change intentional and local to the field the customer selected. Do not log the value, include it in analytics events, echo it into an error message, or copy it into a separate status panel. If the customer submits while the value is showing, the GOV.UK pattern advises returning the input type to password, limiting the chance that a browser later treats it like ordinary text. Avoid making broad claims that a show button itself secures an account; it only helps a person verify entry. Authentication, transport protection and server handling remain separate responsibilities. In a shared space, the customer decides whether immediate visual checking outweighs shoulder-surfing risk.

Handle errors without increasing exposure

Consider two different errors. A blank field can be identified directly, with a message that tells the customer to enter a password. An incorrect sign-in should not reveal whether the account name or password was the failing credential; GOV.UK's password guidance warns that this detail can help attackers. Its example also clears the entered password after an incorrect sign-in. The customer can still use the visibility option on the next attempt. Keep the field label, error text and button name distinct so assistive technology does not announce a jumble of unrelated words. Test the error state with the password both masked and temporarily visible before deciding how the control should reset.

A show control can reduce one source of typing errors, but it does not justify silently truncating passwords or changing characters. GOV.UK cautions against a maxlength restriction because a pasted or autofilled value can be cut without useful feedback. If the service has an actual technical restriction, explain it consistently where the password is created and used, and show an explicit error when it is exceeded. Do not turn on autocapitalisation or spelling correction for a revealed password. The customer should see exactly what the application will submit. On mobile, check that a browser's own reveal affordance does not conflict with yours; the GOV.UK component notes that built-in tools can create duplicate or mismatched controls.

Test a complete customer path

Run the journey on a desktop keyboard without touching the pointer. Tab to the password field, enter a harmless test value, reach the show button, activate it, then hide it and submit. The order of focus should be understandable, and the button should not behave like the form's submit action. Repeat with a screen reader to confirm that the field has a useful name and the button's announced action changes. Use a speech-input test as a separate check if that is part of the audience. Then repeat in Traditional Chinese and listen to the actual labels, rather than checking a translation spreadsheet alone. The goal is a usable decision at the exact point of entry.

Include autofill, paste, and failed sign-in in the same test plan. For creation or change, try a generated password and verify that show and hide do not prevent saving it in a manager. For sign-in, try an existing credential and check that the autocomplete hint points to the correct purpose. After a failed attempt, make sure no password appears in page text, console messages or a support-facing record. Test on a narrow mobile screen in a shared-space scenario: can the customer identify the control, and can they quickly return to masking? If the page has two password fields, verify each toggle affects only its corresponding field. Record any browser-specific duplicate reveal control as a real defect to assess.

Decide what to ship

A small team can make the release decision with a short evidence record: a masked default, a labelled reversible button, preserved value and focus, working paste and manager autofill, and a safe error state. These checks are more useful than debating whether an eye icon looks familiar. Include the exact English and Chinese labels in the review, the browsers and assistive technologies used, and any unresolved mismatch. If an implementation cannot keep the password stable or cannot name the button reliably, fix that implementation before treating the feature as ready. The customer should never have to choose between checking an entry and completing a reliable sign-in.

A final edge case is a customer who begins on a private desktop and continues on a shared phone. Visibility is a momentary choice, not a persistent account preference. The phone should begin masked even if the desktop field was shown earlier. Likewise, the control should return to its default after a fresh page load or a completed sign-in. If the application keeps a client-side view mounted between route changes, check that a previously revealed value is not displayed when the customer returns. This review is about what a bystander could actually see, not only about the input's initial HTML attribute. Ask a tester to leave the page, navigate back, rotate the phone and reopen the browser tab while using harmless sample credentials.

Keep the implementation notes precise for the next developer. State which element owns the password value, which button changes its visibility, how the button name updates, and what happens on submit and error. A screenshot of a masked field is insufficient because the dangerous states occur after interaction. Include a short recording or written sequence from a real test environment if your internal review process permits it, without capturing any actual password. Revisit the behavior when changing the login component, because manager autofill and browser reveal controls can differ between devices. The decision to ship rests on observed behavior through the complete sequence, with no need to claim that the design prevents all credential theft.