Back to compare picker

Transfer list vs Multi-select vs Listbox vs Checkbox group

Prefer transfer list when the task is explicitly moving items from an available set to a selected set and users need to compare both sets while they work.

Decision dimensions

Dimension Transfer listMulti-selectListboxCheckbox group
UI or UX UI + UX - Two-pane item transfer and selected-set reviewUI + UX - Multi-value picker widgetUI + UX - Visible selectable option listUI + UX - Multiple-choice form control
UI guidance Render two clearly labelled panes for available items and selected items, with item counts, selected-row state, disabled move state, and action buttons positioned between or near the panes.Render a filter input, open option list, selected-value chips, remove controls, checked option states, clear-all control, and validation state.Render a labelled listbox container, visible options, active option styling, selected option state, optional grouped labels, empty or disabled states, and nearby help or error text.Render visible native checkboxes with labels, checked states, group legend, select-all-that-apply hint, and group validation state.
UX guidance Use a transfer list when users must build a selected set by moving items from one visible collection to another and then review what will be submitted.Help users choose multiple values from a large, compact, or dynamic option set.Use a listbox when users benefit from seeing the available options while moving focus through the list and selecting one or more static values.Let users choose independent options and review the selected set before submitting.
Good UI A permissions editor shows Available permissions on the left, Selected permissions on the right, selected counts in both headers, Add and Remove buttons between panes, and Move up and Move down controls for selected permissions.Selected values are shown as removable chips or checked rows with clear labels.A Role listbox has a visible label, five role options, one active row, one selected row, concise option names, and a status line explaining whether focus or selection changed.Visible checkboxes with large hit areas, persistent labels, group legend, and aligned helper text.
Bad UI A form shows one long source list and a tiny submitted count, so users cannot review which items were moved before saving.Selected values hidden inside a closed dropdown.Each option row contains nested Edit and Delete buttons, making the listbox a broken table of actions.Tiny custom boxes that are hard to target.
Good UX A user selects Billing and Audit logs, activates Add, hears that two permissions moved to Selected, and focus stays in a useful place for adding another permission.Users can search, add, remove, review, and submit multiple values without losing context.A user arrows from Analyst to Support, hears the active option change, then presses Select active option to commit Support.Clicking the label toggles the checkbox.
Bad UX A user removes the only required item and the form waits until final submit to reveal the selected set is invalid.Removing a value is impossible by keyboard.A high-stakes role assignment saves as soon as focus moves while the user is only exploring options.Using checkboxes for mutually exclusive choices.
Best fit Users build a selected set by moving items from an available collection to a selected collection.Users choose many values from a long predefined list.Users choose one option from a visible static list.Users can choose zero, one, or many options.
Avoid when The option set is short enough for a checkbox group.The set is short and independent choices should stay visible.A native select, radio group, or checkbox group can satisfy the interaction.Only one option can be selected.
Required state Available list initial state with label, count, and selectable options.No selected values state with empty selected set.Empty or initial state with visible label and at least one option.Unchecked option state.
Accessibility burden Give each list pane a visible label and programmatic accessible name.Expose selected state for options and labels for remove controls.Use role listbox on the container and role option on every selectable item.Use programmatic labels for every checkbox.
Common misuse Using transfer list for a short yes-or-no set that should be checkboxes.Hiding selected values inside a closed menu.Using listbox when native select, radio buttons, or checkboxes would do the job with less risk.Using checkboxes for mutually exclusive choices.

Transfer list

UI or UX
UI + UX - Two-pane item transfer and selected-set review
UI guidance
Render two clearly labelled panes for available items and selected items, with item counts, selected-row state, disabled move state, and action buttons positioned between or near the panes.
UX guidance
Use a transfer list when users must build a selected set by moving items from one visible collection to another and then review what will be submitted.
Good UI
A permissions editor shows Available permissions on the left, Selected permissions on the right, selected counts in both headers, Add and Remove buttons between panes, and Move up and Move down controls for selected permissions.
Bad UI
A form shows one long source list and a tiny submitted count, so users cannot review which items were moved before saving.
Good UX
A user selects Billing and Audit logs, activates Add, hears that two permissions moved to Selected, and focus stays in a useful place for adding another permission.
Bad UX
A user removes the only required item and the form waits until final submit to reveal the selected set is invalid.
Best fit
Users build a selected set by moving items from an available collection to a selected collection.
Avoid when
The option set is short enough for a checkbox group.
Required state
Available list initial state with label, count, and selectable options.
Accessibility burden
Give each list pane a visible label and programmatic accessible name.
Common misuse
Using transfer list for a short yes-or-no set that should be checkboxes.

Multi-select

UI or UX
UI + UX - Multi-value picker widget
UI guidance
Render a filter input, open option list, selected-value chips, remove controls, checked option states, clear-all control, and validation state.
UX guidance
Help users choose multiple values from a large, compact, or dynamic option set.
Good UI
Selected values are shown as removable chips or checked rows with clear labels.
Bad UI
Selected values hidden inside a closed dropdown.
Good UX
Users can search, add, remove, review, and submit multiple values without losing context.
Bad UX
Removing a value is impossible by keyboard.
Best fit
Users choose many values from a long predefined list.
Avoid when
The set is short and independent choices should stay visible.
Required state
No selected values state with empty selected set.
Accessibility burden
Expose selected state for options and labels for remove controls.
Common misuse
Hiding selected values inside a closed menu.

Listbox

UI or UX
UI + UX - Visible selectable option list
UI guidance
Render a labelled listbox container, visible options, active option styling, selected option state, optional grouped labels, empty or disabled states, and nearby help or error text.
UX guidance
Use a listbox when users benefit from seeing the available options while moving focus through the list and selecting one or more static values.
Good UI
A Role listbox has a visible label, five role options, one active row, one selected row, concise option names, and a status line explaining whether focus or selection changed.
Bad UI
Each option row contains nested Edit and Delete buttons, making the listbox a broken table of actions.
Good UX
A user arrows from Analyst to Support, hears the active option change, then presses Select active option to commit Support.
Bad UX
A high-stakes role assignment saves as soon as focus moves while the user is only exploring options.
Best fit
Users choose one option from a visible static list.
Avoid when
A native select, radio group, or checkbox group can satisfy the interaction.
Required state
Empty or initial state with visible label and at least one option.
Accessibility burden
Use role listbox on the container and role option on every selectable item.
Common misuse
Using listbox when native select, radio buttons, or checkboxes would do the job with less risk.

Checkbox group

UI or UX
UI + UX - Multiple-choice form control
UI guidance
Render visible native checkboxes with labels, checked states, group legend, select-all-that-apply hint, and group validation state.
UX guidance
Let users choose independent options and review the selected set before submitting.
Good UI
Visible checkboxes with large hit areas, persistent labels, group legend, and aligned helper text.
Bad UI
Tiny custom boxes that are hard to target.
Good UX
Clicking the label toggles the checkbox.
Bad UX
Using checkboxes for mutually exclusive choices.
Best fit
Users can choose zero, one, or many options.
Avoid when
Only one option can be selected.
Required state
Unchecked option state.
Accessibility burden
Use programmatic labels for every checkbox.
Common misuse
Using checkboxes for mutually exclusive choices.
Decision rules
  • Prefer transfer list when the task is explicitly moving items from an available set to a selected set and users need to compare both sets while they work.
  • Prefer transfer list over multi-select when the selected set has its own order, minimum or maximum count, required locked items, or a separate destination label such as Selected permissions or Chosen upgrades.
  • Prefer multi-select when the main burden is finding several values in a long or remote option set and the selected values can be reviewed as chips or tags outside a compact picker.
  • Prefer a standalone listbox when users choose or inspect options within one list and there is no destination list or transfer action.
  • Prefer checkbox group when the option set is short enough to keep every independent choice visible without shuttle buttons, counters, source and destination panes, or custom listbox focus management.
  • Do not use transfer list on narrow mobile views unless the design provides a stacked equivalent with clear add, remove, and destination-review actions.
  • Use disabled move and reorder buttons to communicate unavailable actions; do not hide the controls or let empty selections trigger no-op moves.
  • When selected item order matters, provide explicit move-up and move-down controls and announce the new position instead of relying only on drag and drop.
  • When many available items exist, add filtering or grouping to the source pane without hiding already selected destination items.
  • Avoid transfer list when users only need a yes-or-no toggle, one value, or a command action; those jobs belong to switch, select, radio, button, or menu patterns.
Inspect live examples
Failure modes
  • Users move items to the right pane but cannot tell which values will be submitted because selected counts, pane labels, or review state are missing.
  • The selected pane order is persisted but there is no keyboard-accessible way to move selected items up or down.
  • Move buttons remain enabled when no source item is selected, so users repeatedly activate controls that cannot change anything.
  • Filtering the available pane removes selected items from the destination pane and silently changes the submitted value.
  • A compact multi-select job is forced into two large panes, making a simple tag picker slower and harder on small screens.
  • A source list and destination list expose options without aria-selected, aria-multiselectable, accessible labels, or live-region feedback after moves.