UX Patterns Guide
Back to compare picker

Radio group vs Select

Prefer radio groups when a short mutually exclusive set should stay visible for comparison before the user commits.

Radio group live exampleSelect live example

Decision dimensions

Dimension Radio groupSelect
UI or UX UI + UX - Single-choice form controlUI + UX - Single-choice dropdown control
UI guidance Render a fieldset/legend with visible native radio options, selected state, focus state, optional hints, and group-level validation.Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance Help users compare the available options and choose exactly one without opening an extra control.Help users choose one value from a moderate known list without showing every option permanently.
Good UI Visible native radio options with a clear legend, selected state, focus state, and helper text.Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI Custom circles that do not show focus or selected state clearly.Placeholder as the only label.
Good UX Exactly one option is selected at a time and labels are clickable.Users can open, scan, choose one value, and review the selected value after close.
Bad UX Using radios for choices where multiple selections are allowed.Hiding two obvious critical choices in a dropdown.
Best fit Users must choose exactly one option.The user chooses one option from a moderate known list.
Avoid when Users can choose multiple options.The option set is short and comparison matters.
Required state No selection state for required unanswered groups.Closed state with empty option or current selected value.
Accessibility burden Use a programmatic group label through fieldset/legend or an accessible radiogroup name.Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse Using radios for independent choices where several answers can be true.Custom select with no keyboard support or hidden selected state.

Radio group

UI or UX
UI + UX - Single-choice form control
UI guidance
Render a fieldset/legend with visible native radio options, selected state, focus state, optional hints, and group-level validation.
UX guidance
Help users compare the available options and choose exactly one without opening an extra control.
Good UI
Visible native radio options with a clear legend, selected state, focus state, and helper text.
Bad UI
Custom circles that do not show focus or selected state clearly.
Good UX
Exactly one option is selected at a time and labels are clickable.
Bad UX
Using radios for choices where multiple selections are allowed.
Best fit
Users must choose exactly one option.
Avoid when
Users can choose multiple options.
Required state
No selection state for required unanswered groups.
Accessibility burden
Use a programmatic group label through fieldset/legend or an accessible radiogroup name.
Common misuse
Using radios for independent choices where several answers can be true.

Select

UI or UX
UI + UX - Single-choice dropdown control
UI guidance
Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance
Help users choose one value from a moderate known list without showing every option permanently.
Good UI
Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI
Placeholder as the only label.
Good UX
Users can open, scan, choose one value, and review the selected value after close.
Bad UX
Hiding two obvious critical choices in a dropdown.
Best fit
The user chooses one option from a moderate known list.
Avoid when
The option set is short and comparison matters.
Required state
Closed state with empty option or current selected value.
Accessibility burden
Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse
Custom select with no keyboard support or hidden selected state.
Decision rules
  • Prefer radio groups when a short mutually exclusive set should stay visible for comparison before the user commits.
  • Prefer select when the known list is roughly seven to 15 options, familiar, or secondary enough that one extra open-and-scan step is acceptable.
  • Do not use select to hide a critical short decision just to save vertical space; the extra click makes comparison and error recovery worse.
Inspect live examples
Radio groupSelect
Failure modes
  • Making users open a select repeatedly to compare a short list.
  • Rendering custom selects without native or APG-equivalent keyboard behavior.