Select vs radio vs combobox
All three store one value from a fixed list. A radio group shows every option at once, a select hides them behind a click, and a combobox adds a search box in front of a longer list still. Count the options, and the right one is usually obvious.
The rule
All three do the same job. They store exactly one value from a fixed list, and none of them can hold more than one choice at a time. What changes between them is how many options the list can carry before the control stops working. A radio group shows every option on screen at once, so it only works while all of them fit without a scroll. A select hides the list behind a click, trading one extra step for the room a visible list would have taken. A combobox adds a search box to that same hidden list, and earns the extra build cost only once the list is long enough that scanning it flat is slower than typing three letters. Count the options first. The component almost always follows.
Side by side
| Select | Radio group | Combobox | |
|---|---|---|---|
| Options visible before opening | No | Yes, all of them | No |
| Sweet spot | Roughly 5 to 15 | Roughly 2 to 5 | Past about 15 to 20 |
| Finds an option by typing | Type-ahead jumps to a match | No | Filters the whole list live |
| ARIA pattern | Native <select>, or combobox plus listbox | radio inputs inside a fieldset | combobox plus listbox |
| Build cost | Low with the native element | Lowest, native inputs do all of it | High: filtering, live results, keyboard all at once |
| Common home | A form field with a modest, known list | A short set worth comparing side by side | A long list, like a country or a person picker |
Stripe's billing interval picker uses two radio buttons, monthly and yearly, because two options fit anywhere on the page. Notion's property-type field is a select, holding around a dozen types, few enough to sit behind one click. Linear's "Move to project" picker is a combobox, because a workspace's project list can run past what anyone wants to scroll.
Use a select when
- There's a small to medium, known list of options, roughly 5 to 15
- Exactly one option should be chosen
- The full list doesn't need to stay visible, and showing it would crowd the page
- Nobody needs to search or filter to find the right option
Use a radio group when
- Exactly one option must be chosen from a visible set
- There are roughly 2 to 5 options and the layout has room to show them all
- Comparing the options side by side helps the decision, like a delivery method or a billing interval
Use a combobox when
- The list is long enough, past roughly 15 to 20 options, that scanning it flat is slower than typing a few letters
- Someone is more likely to know part of the value, like the first letters of a name, than its exact position in a list
- The set of valid options is still fixed, even though search changes how it's browsed
Where people get it wrong
The most common miss hides options that were never worth hiding. Two or three choices wearing a select's trigger cost a click a radio group would have avoided for free, since every option was already going to fit on the screen.
The opposite miss shows up once a select's list keeps growing past the point where scanning it works. Fifty country codes in one flat, ungrouped select turn a two-second choice into a scroll-and-squint, and that's exactly the situation a combobox exists for.
The third version builds a combobox for a list short enough to just show. Four payment methods don't need a search box, an aria-activedescendant wired up, and a live filter running on every keystroke. That's real build cost buying nothing a select or a radio group hadn't already solved.
A quick way to check: count the options, then ask if the screen has room for all of them. Room and a short count together mean a radio group. No room but still a short-to-medium count means a select. A count long enough that someone would rather type than scroll means a combobox.
Last reviewed 30 JUL 2026