Form elements - Password input

Help users to create and enter passwords.

<div class="nhsuk-form-group nhsuk-password-input" data-module="nhsuk-password-input">
  <label class="nhsuk-label" for="example">
    Password
  </label>
  <div class="nhsuk-input-wrapper">
    <input class="nhsuk-input nhsuk-password-input__input nhsuk-js-password-input-input" id="example" name="example" type="password" spellcheck="false" autocomplete="current-password" autocapitalize="none">
    <button class="nhsuk-button nhsuk-button--secondary nhsuk-button--small nhsuk-password-input__toggle nhsuk-js-password-input-toggle" data-module="nhsuk-button" type="button" aria-controls="example" aria-label="Show password" hidden>
      Show
    </button>
  </div>
</div>

{% from "password-input/macro.njk" import passwordInput %}

{{ passwordInput({
  label: {
    text: "Password"
  },
  id: "example",
  name: "example"
}) }}

When to use password input

Use this component whenever you need users to create or enter a password.

Before using this component, read:

• the National Cyber Security Centre (NCSC) guidance on password administration for system owners (including their password policy) and NHS England's multi-factor authentication (MFA) policy
• about using NHS login and Care Identity Service (NHS England) for authentication

When not to use password input

Do not use this component to ask for any information other than a password.

Use a text input component to ask for other security information, such as:

• multi-factor authentication codes
• answers to security questions
• other personally identifiable information

Also see GOV.UK's Confirm a phone number pattern.

How to use password input

This component lets users enter a password, with an option to show what they've entered as plain text.

This allows users to visually check their password before they submit it, which helps them reduce errors and choose passwords that are more unique and secure.

Use this guidance with GOV.UK's Ask users for passwords pattern, which explains how to help users create and enter secure and memorable passwords.

The password input component requires JavaScript to work. Without it, users will see a password input but no "Show" button.

Error messages

<div class="nhsuk-form-group nhsuk-form-group--error nhsuk-password-input" data-module="nhsuk-password-input">
  <label class="nhsuk-label" for="example">
    Password
  </label>
  <span id="example-error" class="nhsuk-error-message">
    <span class="nhsuk-u-visually-hidden">Error:</span> Enter a password
  </span>
  <div class="nhsuk-input-wrapper">
    <input class="nhsuk-input nhsuk-password-input__input nhsuk-js-password-input-input nhsuk-input--error" id="example" name="example" type="password" spellcheck="false" aria-describedby="example-error" autocomplete="current-password" autocapitalize="none">
    <button class="nhsuk-button nhsuk-button--secondary nhsuk-button--small nhsuk-password-input__toggle nhsuk-js-password-input-toggle" data-module="nhsuk-button" type="button" aria-controls="example" aria-label="Show password" hidden>
      Show
    </button>
  </div>
</div>

{% from "password-input/macro.njk" import passwordInput %}

{{ passwordInput({
  label: {
    text: "Password"
  },
  errorMessage: {
    text: "Enter a password"
  },
  id: "example",
  name: "example"
}) }}

If the user enters their account details incorrectly, do not reveal whether they got the username or password wrong. Clear any information entered into the password input.

Revealing the source of the error can help fraudsters break into people's accounts.

See how to handle incorrect login attempts and help users who forget their password in GOV.UK's Ask users for passwords pattern.

Showing and hiding passwords

Hide the password by default until the user chooses to show it using the "Show" button. Users might not be in a private space when entering or creating a password, so hide passwords by default.

If you do choose to include 2 or more password inputs on a page, the "Show" and "Hide" toggles and labels for each password input must be different.

For example, you can label:

• the 1st input as "Password" with a toggle of "Show password"
• the 2nd input as "Re-enter password" with a toggle of "Show re-entered password"

Avoid adding a "confirm password" field

It's not necessary to add a 2nd password field, also known as a "confirm password" field, particularly as this component allows users to show and hide passwords.

Define the input's type as "password"

If the form is submitted when the input's text is visible, JavaScript will change the input type back to password. You must check this happens automatically.

This is to prevent browsers from remembering it as a value the user has entered before and potentially displaying it as an autofill option on non-password inputs.

Use the autocomplete attribute

Use the autocomplete attribute on password inputs to help users complete forms faster.

Autocomplete indicates to browsers and password managers what kind of password is needed so it can be entered for the user.

Set the autocomplete attribute to new-password if the user is creating a password. Otherwise, use current-password.

Many browsers will autofill password inputs, even when the autocomplete attribute is missing or set to off.

Allow copy and paste

The NCSC recommends that online services let people:

• use password managers
• paste passwords into web forms

Copying text from password fields

Users can copy any text from a password field when it's set on "Show". This is a feature of browser behaviour and cannot be overridden.

This can be useful for users, for example to save a password that the browser has suggested into a separate password manager.

Avoid restricting the user's input

Support all the characters users may need to enter a password, including numbers and symbols.

Set a minimum length of at least 12 characters.

If you need to set a maximum password length on the server to prevent buffer overflow attacks without discouraging strong passwords, allow at least 64 characters.

The NCSC password policy includes advice on technical solutions and reducing the burden on users.

Any restrictions must be identical wherever the user creates or enters a password. If you change the restrictions over time, you must continue to support existing user passwords or ask them to set a new one.

Do not use maxlength to restrict password length

Users will not get any feedback when they've reached the maxlength and their text input has been truncated. This happens when a user has pasted text from elsewhere or it's been autofilled by a password manager.

If a user exceeds the maximum length, show an error message instead. See GOV.UK's pattern for helping users to recover from validation errors .

Do not spell-check or autocapitalise the user's input

Some browsers might automatically change what the user is typing when the input's text is visible, such as correcting spelling or automatically turning on upper case letters at the start of sentences.

You can tell browsers not to correct spellings by setting the spellcheck attribute to false.

Doing this can avoid making your service vulnerable to "spell-jacking", where some spell-checking tools gather personal identifiable information, even user's passwords, from password input fields to send to third party services.

You can tell browsers not to autocapitalise values by setting the autocapitalize attribute to off.

Known issues

Some apps and tools add their own native functionality to show and hide passwords.

These tools include:

• browsers (particularly when suggesting new passwords)
• password managers
• screen readers

We've tried to minimise duplicate functionality by hiding other types of "Show password" button where possible.

There are also other instances where a password could be shown or hidden without the use of a button, causing a mismatch with the button label. In other words, the user would see a button to show a password that's already visible.

GOV.UK found this mismatch happens in some browsers when:

• a keyboard shortcut is pressed
• a suggested password is created

Accessibility

Follow WCAG 2.2 on accessible authentication (W3C).

Research on this component

GOV.UK decided that having a 2nd field is not helpful for users, particularly on password inputs with show and hide buttons.

We would like to see real-life examples from service teams and get your feedback.

Help us improve this guidance

Share insights or feedback and take part in the discussion. We use GitHub as a collaboration space. All the information on it is open to the public.

Read more about how to feed back or share insights.

If you have any questions, get in touch with the service manual team.

Updated: November 2025