Dropdown or radio buttons — which to use in a form

A dropdown looks tidier. One line, no stretching of the form, everything neatly packed away. So everything gets stuffed into it: country, city, request type, yes/no.

Here's how the GOV.UK Design System sees that. Their guidance on the select component opens by saying it should be used only as a last resort in public-facing services, because research shows some people find it very hard to use.

Let's work out where that really matters and where you can relax.

What each one does

Radio buttons show every option at once; you pick one. A dropdown hides the options behind a single line; opening it is a separate action.

The difference isn't looks. It's when the person sees the options: before choosing, or only after they work out they should tap.

Comparing on criteria you can actually see

• Number of actions. Radios: one tap. Dropdown: open, scroll, select, close — and on a phone that's a system sheet sliding over your form.
• Visibility of options. With radios, people see the whole set and understand the question before answering. With a dropdown, the question only makes sense to whoever already opened it.
• Comparing options. "Express, $5" and "Standard, $2" next to each other compare themselves. In a dropdown you have to hold them in your head.
• Screen space. Here the dropdown wins, and it's its one genuine advantage: thirty options as radios is a screenful of scrolling.
• Protection from nonsense. A dropdown can't receive a value that isn't in the set. NN/g counts this as a real plus: the data arrives already legal.
• Small screens and accessibility. This is where dropdowns fall apart, and it's documented. GOV.UK lists what they saw in research: people couldn't close the select, tried to type into it, confused the focused option with the selected one, tried to pinch-zoom the options, and didn't realise the list could be scrolled further.

Who should use what — the straight answer

• Two options — radios, always. A two-item dropdown is three actions where one would do.
• Three to five options — radios. They fit, they read, they compare.
• Six to fifteen — it depends. If the options are short and worth comparing, still radios. If it's a background setting, a dropdown is fine.
• More than fifteen and the list is familiar — use a text field with autocomplete. NN/g explicitly advises against dropdowns where typing is faster; country and region are the standard examples. Typing "Ca…" and picking from three suggestions beats hunting through two hundred entries.
• Date of birth — never a dropdown. NN/g has a separate guideline: don't bury data people know by heart, because day, month and year are "hardwired into users' fingers" and a long menu turns one second into thirty. Three text fields are better — just don't put an input mask on them.

About that "tried to type into the select". People don't do it out of confusion: on a desktop, typing in an open <select> genuinely works — the browser jumps to the option starting with those letters. Almost nobody knows it, and on a phone it doesn't exist at all. Hence NN/g's advice to keep keyboard input working in dropdowns and not break it with your own scripts: for anyone who knows the trick, it's the fastest way to pick from two hundred countries. Build your own "prettier" list out of divs and you've taken that away, along with screen reader support. In a contact form that trade almost never pays off.

There's also a "neither" option: sometimes the right move is to ask a different question. GOV.UK suggests first trying to rephrase so there are fewer options at all. A twelve-item "select a request type" often unfolds into two simple questions with three options each — and fills in faster.

Two traps that catch both controls

A pre-selected option. Fine in settings. Not fine in a question: GOV.UK warns that a pre-selected answer influences what people answer, and some will scroll past without noticing it at all.

No way to un-answer. A radio button can't be returned to "nothing selected" without reloading the page. So if "I don't know" or "none of these" is a valid answer, add it as an explicit option.

Both are usually fixed by rewording the question rather than by code.

What if there really are thirty options?

Then a dropdown beats radios — but a text field with suggestions beats both. Keep the options in one predictable order (alphabetical, years ascending) and keep the label visible: NN/g notes specifically that the label should stay in view while the dropdown is open, or people forget what they're choosing.

Won't radios stretch the form on mobile?

They will, and that's fine: vertical scrolling on a phone is cheaper than a system picker sheet. Stack them, and make the whole labelled row tappable, not just the circle. Then check it on a real phone, like the rest of your mobile layout.