Figma multi-select components

Assigning three reviewers to a pull request, tagging a contact with five labels, picking the countries a price applies to: these are all the same interaction, and a single-value field cannot do any of them.

A multi-select can, at the cost of a design problem the single-value version never has, which is that the chosen values need somewhere to live. The 4 multi-select components and 21 variants above answer that with tags inside the field itself.

Multi-select or select?

A select stores one value and displays it as text. A multi-select stores a set with no fixed size, so the field has to hold anywhere from zero to a dozen items, each individually removable.

That is why the component has a distinct Active state rather than treating selections as ordinary content: an empty field and a field carrying six tags are different heights, different reading tasks, and different targets.

If you only ever expect two or three options and you have the room, a column of checkboxes shows everything at once and beats this component outright. Multi-select earns its place when the list is long, the typical selection is small, and searching is faster than scrolling.

The field grows, so plan for it

Tags inside an input change its height as they accumulate, and on a narrow column they wrap to a second and third line, pushing everything below them down the page. Nothing breaks, but forms designed at one tag per field look very different at seven.

Build the field with auto layout set to wrap and hug its contents, then mock up the crowded case before you sign anything off. The tag components used inside the field are the same ones from the rest of the kit, so removing one is a real dismiss target rather than a decorative x.

Three sizes and the states nobody remembers

The component ships in sm, md, and lg, with option rows at 38px, 42px, and 46px respectively, in default, hover, and disabled versions.

Beyond the usual default, focused, and disabled field states sit three that most kits skip and every real product needs. Active covers the field once selections exist. Open active covers the menu showing while values are already chosen, which is the state where a user is halfway through a task.

And the search empty state covers a query that matches nothing, the screen almost no mockup contains and almost every user eventually sees. Guessing at that one in production is how you end up with an empty white rectangle and no explanation. The set is drawn twice, once for light and once for dark.

What it becomes in code

Worth knowing before handoff: a combobox is a single-value widget by definition. The W3C combobox pattern is explicit that it allows only one suggested value to be selected at a time, so a multi-select is not simply a combobox with a flag flipped.

It is a text input paired with a multi-selectable listbox, and the selected values need to be announced and removable on their own, typically with Backspace clearing the last tag. Designing the removal target now, at every size, is what stops that behavior from being invented at the end of a sprint.

When it is time to build, the same fields exist in code. Untitled UI React multi-selects are open source, built with Tailwind CSS and React Aria, with filtering, keyboard removal of selected values, and listbox semantics handled for you.