Multi Select
Lets users select multiple options from a dropdown list, with optional grouping.
When to use
Section titled “When to use”- Users can select more than one option from the same list, and selections persist until explicitly changed.
- The list is long or requires scrolling. Collapsing it keeps the layout compact as selections accumulate.
- Screen space is limited, so showing every option as an inline checkbox group isn’t feasible.
- Selections need to be reviewed or removed individually after the list closes, for example as dismissible chips below the field. See the chips example.
- The list of options may change based on context, such as depending on another field’s value or loading from data at runtime.
- Users know the option they want. Typing its first letters jumps to it without a separate search field.
When not to use
Section titled “When not to use”- Users can only choose one option. Use
Selectinstead: it skips affordances like chips and checkbox indicators that add no value for a single choice. - There are 3 or fewer options that users need to see at once. Use a
Checkboxgroup instead: every choice stays visible and selection takes one fewer click. - The choice is a binary decision that takes immediate effect, such as on/off. Use a
Switchinstead. - The options are independent settings rather than one list of values to submit together. Use individual
Checkboxinputs instead. - Users need to search or filter a long list to find options they don’t know by name. Use a searchable combobox instead.
- A few filters need to stay visible on the page rather than collapsed behind a field. Use selectable
Chipsinstead. - The options represent actions to take, such as sort or bulk edit, rather than a value to submit. Use a menu instead.
- Selections need reordering or bulk management. Use a dedicated list or table pattern instead.
Choosing a variant
Section titled “Choosing a variant”Top label
Section titled “Top label”Use a top label by default. It gives longer, translated labels room to grow and keeps the label distinct from the selected values.
Floating label
Section titled “Floating label”Use a floating label only in compact layouts, such as a sidebar or a filter panel, where the vertical space it saves matters more than the benefits of a top label.
Labeling
Section titled “Labeling”Input label
Section titled “Input label”Every MultiSelect needs a concise, visible label. Don’t rely on the placeholder text alone to identify the field.
Selected value
Section titled “Selected value”The closed field shows the first selected option and how many more are selected, for example “EX30 (+2)”. Users see what they picked without opening the list, and the text needs no translation.
Keep the default unless your design needs different text, such as “3 selected”. Then use selectedLabel and translate the text for every language your app supports. See the selected value example.
Option description
Section titled “Option description”Add a description below an option’s title when the label alone isn’t enough to tell options apart or to explain what selecting one means. Keep it to a single supporting line so options stay easy to scan.
Removing selections
Section titled “Removing selections”Users remove a selection by opening the list and unchecking the option. When selections must stay visible and removable without opening the list, also show each one as a dismissible chip below the field. See the chips example.
Grouping options
Section titled “Grouping options”Group options under headings when the list mixes categories, such as car models grouped by body type. Don’t group a short, flat list: the headings have nothing to organize.
Disabled options
Section titled “Disabled options”Keep an option that users can’t select right now in the list as disabled, when its presence helps users understand the choices. This keeps the list stable. Explain why it is unavailable when the reason isn’t clear.
Validation
Section titled “Validation”Validate lazily: show an error after the user changes the selection or submits the form, not before they’ve made a choice.
Marking required fields
Section titled “Marking required fields”Mark whichever fields are fewer. If most fields in a form are required, mark the optional ones instead of marking every required one.
Layout and spacing
Section titled “Layout and spacing”Stack form fields vertically. It’s easier to scan and complete than a multi-column layout. Group two fields on the same line only when they have a clear logical relationship, such as city and postal code.
Use these spacings between fields:
- 24px between stacked fields.
- 16px between fields placed side by side.
- 8px between a field and its label, and between a field and its hint or error message.
Match the field’s width to its container. On mobile, span the full width between margins; on desktop, keep every field in a form the same width for visual alignment.