Skip to main content

Looking for the HTML version? See Text field (HTML)

Variations
<bolt-password label="Password" required instructionaltext="Case sensitive"></bolt-password>
<bolt-password label="Password" required instructionaltext="Case sensitive" showvisibilitytoggle></bolt-password>
<bolt-password label="Password" required invalid></bolt-password>

maxlength controls the number of characters that may be entered. And inputsize specifies the visible width, in characters, of an <input> element.

<bolt-password label="Password" maxlength="20" required instructionaltext="Case sensitive" showvisibilitytoggle inputsize="20"></bolt-password>
<bolt-password label="Password" required instructionaltext="Case sensitive">
    <bolt-contextual-help slot="help" heading="Heading">
        <p>Lorem ipsum dolor sit amet, <i>consectetur adipiscing</i> elit. <strong>Nunc nibh</strong> velit, viverra vel elit.</p>
    </bolt-contextual-help>
</bolt-password>
Code reference

The web component implementation reduces the need for explicitly-defined behavioral logic. However, it provides limited control over the underlying HTML markup.

If you require full control over the HTML markup, check out the HTML implementation of text field.

The <bolt-password> custom element creates a password input field with a label and optional instructional and error text:

<bolt-password label="Password" required instructionaltext="Case sensitive"></bolt-password>

The custom element supports the following parameters:

  • label: required. The label text for the input.
  • value: optional. The initial or set value for the input.
  • instructionaltext: optional. The instructional text to display below the input. This should be used to give users additional information about the expected content in the field.
  • required: optional. If present, the field is required. Fields that are not required will show "(optional)".
  • optionaltext: optional. show (default) or hide. Use to remove the "(optional)" text from non-required fields.
  • disabled: optional. If present, disables rendered interactive elements.
  • error: optional. The error message to display after the input.
    • Should not be used when component is disabled.
  • maxlength: optional. Maximum allowed input length.
  • inputsize : optional. Sets the width of the input box in terms of average character widths. If not specified, the input box will span the full width of its container.
  • showvisibilitytoggle: optional. If present, the field includes a show/hide icon button.
  • invalid: optional. If present, the field appears invalid.
  • iconalthide : optional. The alt text for the icon that can be clicked to hide contents of the password field. Defaults to 'hide password'.
  • iconaltshow : optional. The alt text for the icon that can be clicked to show contents of the password field in plain text. Defaults to 'show password'.
  • datatestinput optional property to configure the data-test value on the underlying <input> element. Default is input.
  • datatestbutton optional property to configure the data-test value on the underlying <button> element. Default is button.

The <bolt-password> element supports the use of <bolt-contextual-help> via the help slot placeholder. For more information and to see other options visit the contextual help page.

The following attributes are passed through to the native <input> element. Please see the MDN Input element documentation for details.

  • [data-test="input"] targets primary <input> element

    • Configurable via the datatestinput property
  • [data-test="button"] targets <button> element (show/hide button)

    • Only used on the a show/hide button
    • Configurable via the datatestbutton property
Design guidelines
  • Autocorrect and autocapitalize features should be disabled for password fields.
  • Alphanumeric data cannot be cut or copied from password fields, but it can be pasted into password and confirm fields.
  • Error and disabled states should not be used at the same time.
  • Use confirm (re-type) fields when collecting a password. The time and effort it can take a user or company to correct this information later can be significant. Entering this information twice on a form takes a fraction of that time and effort.
  • When creating a password for an account, don’t hide security requirements behind an error. Give the user notice up-front as to what requirements they need to meet.
  • When setting a password, provide feedback for meeting all security requirements for valid passwords in validation messaging. (e.g., You must include a special character.)
  • Validation and error messaging should, depending on the context of use, occur after users either:
    • submit a form (form-level validation)
    • enter one or more characters (delayed onInput, mid-form validation)
    • exit the field (onBlur, frontend validation only)
  • If user input is not allowed, both Password and confirm fields should be disabled.
  • On touch devices, the active state should invoke an alphanumeric virtual keyboard for Password fields.
  • Validation and error messaging should, depending on the context of use, occur only after a user submits a form (form-level validation).
  • When validating username and Password fields, never tell the user which one is wrong. For both the system and user’s security, only display a generic message similar to: “The username or password doesn't match our records. Please check your information and try again.”
  • Use when users need to provide secure data that should be hidden or shown while entered.
  • Do not use Password if asking users to provide data not considered security-sensitive.

Do

  • Mask the input of the user by default.
  • Allow the user to toggle the viewability of their input.
  • Call out constraints using instructional or hint text (e.g., "Maximum 12 characters").

Don't

  • Don’t use if a user is being asked to provide data that is not considered to be security sensitive.
  • Don’t hide security requirements behind messaging.
  • When users are creating a password for signing up for an account, provide feedback for meeting all security requirements for valid passwords.
Accessibility
  • WCAG 2.2 Compliant
  • JAWS 2025 Tested
  • NVDA 2025 Tested
  • VoiceOver Tested
  • Keyboard Tested
  • aXe Tested
  • It is important for form field labels to always remain visible, to help users understand what they're working with. Placeholder text, or text inside the form field, should not be used as a label because it disappears when the user starts typing. This can be confusing, especially for people with cognitive disabilities who might forget what the field is for. It's also a problem for those who use speech-to-text tools because it makes it hard to understand what to say to activate the field.

All Bolt components have gone through accessibility testing, but please keep our accessibility guidelines in mind.

Display settings

Note: not all settings persist across pages

Default Compact (-1) Sparse (+1) XL (default) 2XL 3XL Default Min Max Light (default) System Dark Branded (default) Unbranded