Bootstrap/site/docs/4.5/components/input-group.md

layout	title	description	group	toc
docs	Input group	Easily extend form controls by adding text, buttons, or button groups on either side of textual inputs, custom selects, and custom file inputs.	components	true

Basic example

Place one add-on or button on either side of an input. You may also place one on both sides of an input. Remember to place <label>s outside the input group.

{% capture example %}

@

@example.com

Your vanity URL

https://example.com/users/

$

.00

With textarea

{% endcapture %} {% include example.html content=example %}

Wrapping

Input groups wrap by default via flex-wrap: wrap in order to accommodate custom form field validation within an input group. You may disable this with .flex-nowrap.

{% capture example %}

@

{% endcapture %} {% include example.html content=example %}

Sizing

Add the relative form sizing classes to the .input-group itself and contents within will automatically resize—no need for repeating the form control size classes on each element.

Sizing on the individual input group elements isn't supported.

{% capture example %}

Small

Default

Large

{% endcapture %} {% include example.html content=example %}

Checkboxes and radios

Place any checkbox or radio option within an input group's addon instead of text.

{% capture example %}

{% endcapture %} {% include example.html content=example %}

Multiple inputs

While multiple <input>s are supported visually, validation styles are only available for input groups with a single <input>.

{% capture example %}

First and last name

{% endcapture %} {% include example.html content=example %}

Multiple addons

Multiple add-ons are supported and can be mixed with checkbox and radio input versions.

{% capture example %}

$ 0.00

$ 0.00

{% endcapture %} {% include example.html content=example %}

Button addons

{% capture example %}

Button

Button

Button Button

Button Button

{% endcapture %} {% include example.html content=example %}

Buttons with dropdowns

{% capture example %}

Dropdown

Action Another action Something else here

Separated link

Dropdown

Action Another action Something else here

Separated link

{% endcapture %} {% include example.html content=example %}

Segmented buttons

{% capture example %}

Action Toggle Dropdown

Action Another action Something else here

Separated link

Action Toggle Dropdown

Action Another action Something else here

Separated link

{% endcapture %} {% include example.html content=example %}

Custom forms

Input groups include support for custom selects and custom file inputs. Browser default versions of these are not supported.

Custom select

{% capture example %}

Options

Choose... One Two Three

Choose... One Two Three

Options

Button

Choose... One Two Three

Choose... One Two Three

Button

{% endcapture %} {% include example.html content=example %}

Custom file input

{% capture example %}

Upload

Choose file

Choose file

Upload

Button

Choose file

Choose file

Button

{% endcapture %} {% include example.html content=example %}

Accessibility

Ensure that all form controls have an appropriate accessible name so that their purpose can be conveyed to users of assistive technologies. The simplest way to achieve this is to use a <label> element, or—in the case of buttons—to include sufficiently descriptive text as part of the <button>...</button> content.

For situations where it's not possible to include a visible <label> or appropriate text content, there are alternative ways of still providing an accessible name, such as:

• <label> elements hidden using the .visually-hidden class
• Pointing to an existing element that can act as a label using aria-labelledby
• Providing a title attribute
• Explicitly setting the accessible name on an element using aria-label

If none of these are present, assistive technologies may resort to using the placeholder attribute as a fallback for the accessible name on <input> and <textarea> elements. The examples in this section provide a few suggested, case-specific approaches.

While using visually hidden content (.sr-only, aria-label, and even placeholder content, which disappears once a form field has content) will benefit assistive technology users, a lack of visible label text may still be problematic for certain users. Some form of visible label is generally the best approach, both for accessibility and usability.