ui patterns
Dropdown / select menu
When should you use a dropdown (select) menu?
A dropdown (select) menu lets someone pick one option from a list that stays collapsed until opened, saving space when there are many choices. It's the right tool for long, familiar lists - countries, months, quantities - but a poor one for short sets or important choices, where hiding the options behind a click costs more than it saves.
Also known as: dropdown menu, select menu, select dropdown
Prefer to watch?
Watch the recap 1:04
The demo
A small choice - “how would you like updates?” - shown as a dropdown and as radio buttons. Then a long list where the dropdown earns its keep. Notice when hiding the options helps and when it just hurts.
…and here a dropdown is the right call - a long, familiar list:
What this demo shows (text version)
A small choice with three options is shown as a dropdown (collapsed until you open it) and as radio buttons (all options visible at once). For a short set the radio buttons are clearer - everything is visible, comparable and one tap away - while the dropdown hides the options and needs two taps. A second example, a country list with 190+ options, shows where a dropdown's space saving genuinely wins.
That's the dropdown trade-off: it saves space by hiding options, which pays off only for long, familiar lists. For a few important choices, radio buttons or a segmented control are usually better. Prefer the native select for accessibility, and decide by list length and importance - few and important means show them; many and routine means a dropdown.
A dropdown trades visibility for space: it hides the options until tapped, which is worth it only when there are many of them. For a handful of choices (2-5), radio buttons or a segmented control are usually better - all options visible at once, one tap to choose, easier to compare, no hidden state. Use a dropdown when the list is long and familiar (countries, years), the options don't need comparing, and space is tight. Prefer the native select control - it's accessible, familiar and works on every device - over custom dropdowns unless you genuinely need richer content, and even then build accessibility in. The rule of thumb: few and important → show them; many and routine → a dropdown.
As a dropdown, the choice was tidy but hidden - you had to open it to see or compare the options. As radio buttons, the same few options were all visible and one tap away. That's the trade-off: dropdowns save space by hiding, which only pays off when the list is long. For a short, important set, showing the options beats tucking them away.
Dropdowns hide their options behind an interaction, which has real costs: people can't see or compare choices without opening the menu, selection takes at least two taps (open, then pick), they're fiddly on touch, and the hidden state increases recognition effort. Those costs are worth paying when the benefit - saving space on a long list - is large, but not when the list is short.
Choose by list length and importance. For 2-5 options, radio buttons (single choice) or a segmented control keep everything visible, comparable and one tap away, which is faster and clearer. For long, familiar lists (countries, dates, quantities) a dropdown's space saving wins. For frequently-changed or important settings, visibility usually beats tidiness. Steppers suit small numeric ranges; search or autocomplete beats a giant dropdown of hundreds.
Prefer the native HTML select: it's keyboard- and screen-reader-accessible, familiar, and renders sensibly (often full-screen) on mobile. Reach for a custom dropdown only when you need richer content (icons, descriptions, grouping, multi-select) - and then you must rebuild keyboard support, focus management and ARIA, which is easy to get wrong. Label clearly, set a sensible default or a clear placeholder, and avoid dropdowns for yes/no or tiny choices.