UX Patterns Guide
Back to compare picker

Text input vs Autocomplete vs Select vs Radio group

Use text input for short freeform answers, autocomplete for known values that benefit from typing, select for compact single choice from a finite list, and radio group for short visible mutually exclusive choices.

Text input live exampleAutocomplete live exampleSelect live exampleRadio group live example
Learn the decision

Match the interaction to the person's task

Use text input for short freeform answers, autocomplete for known values that benefit from typing, select for compact single choice from a finite list, and radio group for short visible mutually exclusive choices.

Text input

Use it when: The answer is short and user-authored.

Make this state clear: Empty untouched state with persistent label and optional hint.

Observe the result: A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.

Study the full pattern →

Autocomplete

Use it when: The list is long but values are known.

Make this state clear: Empty input state.

Observe the result: Typing filters suggestions while preserving the exact typed value.

Study the full pattern →

Select

Use it when: The user chooses one option from a moderate known list.

Make this state clear: Closed state with empty option or current selected value.

Observe the result: Users can open, scan, choose one value, and review the selected value after close.

Study the full pattern →

Radio group

Use it when: Users must choose exactly one option.

Make this state clear: Exactly one selected option state.

Observe the result: Exactly one option is selected at a time and labels are clickable.

Study the full pattern →

Practice the judgment: Imagine this situation: A freeform answer is forced into a select, causing users to choose an inaccurate option. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Text inputAutocompleteSelectRadio group
UI or UX UI + UX - Single-line freeform data-entry controlUI + UX - Input widget with suggestion behaviorUI + UX - Single-choice dropdown controlUI + UX - Single-choice form control
UI guidance Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.Expose clear visual states for expanded, focused, highlighted, and selected options.Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.Render a fieldset/legend with visible native radio options, selected state, focus state, optional hints, and group-level validation.
UX guidance Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.Preserve typed input and make selection reversible before submission.Help the person reach a clear task outcome.Help the person reach a clear task outcome.
Good UI A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.Persistent label, hint text, visible selected value, readable options, and clear required validation state.Visible native radio options with a clear legend, selected state, focus state, and helper text.
Bad UI The only instruction is placeholder text that disappears when the user starts typing.Placeholder-only label that disappears after typing.Placeholder as the only label.Allowing several options in the group to appear active at once.
Good UX A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.Typing filters suggestions while preserving the exact typed value.Users can open, scan, choose one value, and review the selected value after close.Exactly one option is selected at a time and labels are clickable.
Bad UX Validation fires on the first focus event and blocks typing before the user has had a chance to answer.Automatically forcing the first suggestion into the field.Hiding two obvious critical choices in a dropdown.Using radios for choices where multiple selections are allowed.
Best fit The answer is short and user-authored.The list is long but values are known.The user chooses one option from a moderate known list.Users must choose exactly one option.
Avoid when The answer is a paragraph, comment, address block, or explanation requiring multiple lines.The task is open-ended query exploration.The option set is short and comparison matters.Users can choose multiple options.
Required state Empty untouched state with persistent label and optional hint.Empty input state.Closed state with empty option or current selected value.Exactly one selected option state.
Accessibility burden Associate every text input with a visible label or equivalent accessible name that matches the visible question.Expose combobox expanded state, active descendant, and option labels.Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.Use a programmatic group label through fieldset/legend or an accessible radiogroup name.
Common misuse Using placeholder text as the only label or instruction.Using autocomplete where users expect broad search results.Using select to hide two or three obvious choices that should be compared.Using radios for independent choices where several answers can be true.

Text input

UI or UX
UI + UX - Single-line freeform data-entry control
UI guidance
Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance
Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text.
Good UI
A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI
The only instruction is placeholder text that disappears when the user starts typing.
Good UX
A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error.
Bad UX
Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit
The answer is short and user-authored.
Avoid when
The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state
Empty untouched state with persistent label and optional hint.
Accessibility burden
Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse
Using placeholder text as the only label or instruction.

Autocomplete

UI or UX
UI + UX - Input widget with suggestion behavior
UI guidance
Expose clear visual states for expanded, focused, highlighted, and selected options.
UX guidance
Preserve typed input and make selection reversible before submission.
Good UI
Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option.
Bad UI
Placeholder-only label that disappears after typing.
Good UX
Typing filters suggestions while preserving the exact typed value.
Bad UX
Automatically forcing the first suggestion into the field.
Best fit
The list is long but values are known.
Avoid when
The task is open-ended query exploration.
Required state
Empty input state.
Accessibility burden
Expose combobox expanded state, active descendant, and option labels.
Common misuse
Using autocomplete where users expect broad search results.

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 the person reach a clear task outcome.
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
Using select to hide two or three obvious choices that should be compared.

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 the person reach a clear task outcome.
Good UI
Visible native radio options with a clear legend, selected state, focus state, and helper text.
Bad UI
Allowing several options in the group to appear active at once.
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
Exactly one selected option state.
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.
Decision rules
  • Prefer text input when the answer is short, user-authored, and cannot be usefully enumerated as a fixed option list.
  • Prefer autocomplete when the user is still typing into a field but the valid answer should resolve to one known record, product, address, tag, or code.
  • Prefer select when the user must choose one value from a finite moderate list and seeing every option at once is not critical.
  • Prefer radio group when the choice set is short, mutually exclusive, and users benefit from comparing every option before deciding.
  • Use textarea instead of text input when the expected answer has sentence or paragraph structure, needs line breaks, or should visibly support extended writing.
  • Use specialized text inputs such as email, password, phone, date, card, prefix/suffix, or input mask only when the answer has domain-specific parsing, keyboard, validation, or privacy behavior.
  • Do not use placeholder text as the only label for text input; persistent labels and nearby hints remain available after typing starts.
  • Do not validate a text input before the user has interacted with it, except for server-returned errors on an attempted submission.
  • Match the visible input width to the expected answer length so users do not infer a paragraph answer from a short field or a short code from a wide field.
  • If the field accepts pasted content or arbitrary text, do not replace it with select, radio, or autocomplete merely to make data cleaner.
Inspect live examples
Text inputAutocompleteSelectRadio group
Failure modes
  • A freeform answer is forced into a select, causing users to choose an inaccurate option.
  • A single-line text input is used for paragraph comments, hiding overflow and making review hard.
  • A placeholder disappears after typing, leaving no persistent label or instruction.
  • Inline validation fires on focus or the first keystroke and blocks normal editing.
  • A short code field is rendered full-width, making users think long prose is expected.
  • A known-value identifier is accepted as arbitrary text even though downstream systems need a selected record ID.

Saved items