Back to compare picker

Toolbar vs Button group vs Menu button vs Command palette

Prefer a toolbar when a view or editor needs a persistent strip of related controls such as Undo, Redo, Bold, Align, Filter, Export, and More, and users benefit from one labelled command region rather than scattered buttons.

Decision dimensions

Dimension ToolbarButton groupMenu buttonCommand palette
UI or UX UI + UX - View-scoped command strip for related controlsUI + UX - Grouped visible action buttonsUI + UX - Button-controlled popup menu of actions or linksUI + UX - Modal command surface
UI guidance Render a toolbar as a labelled command region attached to the view, editor, canvas, table, or selected object it controls, with grouped buttons, toggle buttons, menu buttons, separators, compact inputs, overflow, and current state visible where relevant.Render a small group of visibly related action buttons with one clear scope, one dominant primary action when needed, lower-emphasis alternatives, consistent labels, visible focus, and stable spacing.Render a named button trigger, visible opened state, controlled popup, menu items, active item styling, disabled item state, separator or section grouping, and a safe way to distinguish destructive commands.Render a compact dialog-like command surface with a search input, current scope, typed command mode, active result, command metadata, and empty state.
UX guidance Use a toolbar when users repeatedly apply related commands to the same view or selection and need fast visible access without opening a modal command surface.Use a button group when users need to choose between a few related commands at the same workflow moment, such as saving, continuing, going back, cancelling, applying, resetting, or exporting in one local task.Use a menu button when users need to reveal a short contextual set of commands or links from a single trigger without leaving the current object or toolbar context.Accelerate expert navigation and repeated actions across a large product while preserving ordinary navigation for novice and low-frequency users.
Good UI A document editor toolbar labels the current document, groups Undo and Redo, formatting toggles, alignment controls, Insert link, and More, with Bold shown pressed for the selected text.A form footer shows Save draft, Continue, and Cancel as one named action group, with Continue primary only after required work is saved.A table row has a Report actions button that opens a compact menu with Open, Rename, Duplicate, Archive, and an unavailable Export item.Centered command surface with input, shortcut hint, scope chip, grouped commands, command type labels, and a visible active row.
Bad UI A toolbar contains Back, Save, Delete, Pricing, Account, Filter, and Help with no shared scope or grouping.A footer contains Save, Continue, Delete, Help, View report, and Open settings as identical primary buttons.An unlabeled ellipsis opens a loose panel of buttons, inputs, links, toggles, and destructive commands with no active item.Huge branded modal that buries the input below decorative content.
Good UX A keyboard user tabs once into the editor toolbar, uses Right Arrow to move from Bold to Italic, presses Space to toggle Italic, and focus remains in the toolbar while selected text stays selected.A user saves a draft, sees Continue become available, then continues without losing the saved status or action hierarchy.A user opens Report actions, arrows to Duplicate report, activates it, and focus returns to the Report actions trigger with a status update.Keyboard shortcut or visible trigger opens the palette, focus lands in the command input, arrows move the active row, and Enter activates the highlighted safe command.
Bad UX A keyboard user must tab through twenty toolbar buttons before reaching the editor body.A disabled Continue button gives no reason, so the user repeatedly presses Save, Cancel, and Back to find a path forward.A user tabs into a menu and lands in a text input because the menu contains unrelated form controls.Palette is the only way to reach important navigation.
Best fit A view, editor, canvas, media surface, table, or selection needs repeated related commands close to the work area.A form, dialog, panel, card, or workflow footer needs two to four related visible commands.A local object or toolbar has three to eight secondary commands.Users need to traverse a broad product surface quickly.
Avoid when There are only one or two actions that should be ordinary buttons.The controls are mutually exclusive view modes that need a selected state.The job is choosing a form value, selecting several values, or browsing a long list.The app has only a few obvious actions.
Required state Default toolbar with label, visible scope, grouped controls, and focusable entry point.Default group with a clear label or surrounding context.Closed trigger state with visible or accessible name.Closed state with discoverable trigger.
Accessibility burden Use role toolbar only for a cohesive group of controls whose grouping helps users, and give each toolbar a clear accessible name.Use native button elements for actions so Enter and Space activation, disabled behavior, and focus work predictably.Use an actual button for the trigger when possible.Use dialog semantics with a clear name and modal behavior when the rest of the page is inert.
Common misuse Labelling any horizontal button row as a toolbar without shared scope or keyboard behavior.Putting unrelated actions into one row because the layout has space.Using a menu button for long value selection that should be a select, listbox, combobox, or multi-select.Hiding basic navigation behind a keyboard-only palette.

Toolbar

UI or UX
UI + UX - View-scoped command strip for related controls
UI guidance
Render a toolbar as a labelled command region attached to the view, editor, canvas, table, or selected object it controls, with grouped buttons, toggle buttons, menu buttons, separators, compact inputs, overflow, and current state visible where relevant.
UX guidance
Use a toolbar when users repeatedly apply related commands to the same view or selection and need fast visible access without opening a modal command surface.
Good UI
A document editor toolbar labels the current document, groups Undo and Redo, formatting toggles, alignment controls, Insert link, and More, with Bold shown pressed for the selected text.
Bad UI
A toolbar contains Back, Save, Delete, Pricing, Account, Filter, and Help with no shared scope or grouping.
Good UX
A keyboard user tabs once into the editor toolbar, uses Right Arrow to move from Bold to Italic, presses Space to toggle Italic, and focus remains in the toolbar while selected text stays selected.
Bad UX
A keyboard user must tab through twenty toolbar buttons before reaching the editor body.
Best fit
A view, editor, canvas, media surface, table, or selection needs repeated related commands close to the work area.
Avoid when
There are only one or two actions that should be ordinary buttons.
Required state
Default toolbar with label, visible scope, grouped controls, and focusable entry point.
Accessibility burden
Use role toolbar only for a cohesive group of controls whose grouping helps users, and give each toolbar a clear accessible name.
Common misuse
Labelling any horizontal button row as a toolbar without shared scope or keyboard behavior.

Button group

UI or UX
UI + UX - Grouped visible action buttons
UI guidance
Render a small group of visibly related action buttons with one clear scope, one dominant primary action when needed, lower-emphasis alternatives, consistent labels, visible focus, and stable spacing.
UX guidance
Use a button group when users need to choose between a few related commands at the same workflow moment, such as saving, continuing, going back, cancelling, applying, resetting, or exporting in one local task.
Good UI
A form footer shows Save draft, Continue, and Cancel as one named action group, with Continue primary only after required work is saved.
Bad UI
A footer contains Save, Continue, Delete, Help, View report, and Open settings as identical primary buttons.
Good UX
A user saves a draft, sees Continue become available, then continues without losing the saved status or action hierarchy.
Bad UX
A disabled Continue button gives no reason, so the user repeatedly presses Save, Cancel, and Back to find a path forward.
Best fit
A form, dialog, panel, card, or workflow footer needs two to four related visible commands.
Avoid when
The controls are mutually exclusive view modes that need a selected state.
Required state
Default group with a clear label or surrounding context.
Accessibility burden
Use native button elements for actions so Enter and Space activation, disabled behavior, and focus work predictably.
Common misuse
Putting unrelated actions into one row because the layout has space.

Menu button

UI or UX
UI + UX - Button-controlled popup menu of actions or links
UI guidance
Render a named button trigger, visible opened state, controlled popup, menu items, active item styling, disabled item state, separator or section grouping, and a safe way to distinguish destructive commands.
UX guidance
Use a menu button when users need to reveal a short contextual set of commands or links from a single trigger without leaving the current object or toolbar context.
Good UI
A table row has a Report actions button that opens a compact menu with Open, Rename, Duplicate, Archive, and an unavailable Export item.
Bad UI
An unlabeled ellipsis opens a loose panel of buttons, inputs, links, toggles, and destructive commands with no active item.
Good UX
A user opens Report actions, arrows to Duplicate report, activates it, and focus returns to the Report actions trigger with a status update.
Bad UX
A user tabs into a menu and lands in a text input because the menu contains unrelated form controls.
Best fit
A local object or toolbar has three to eight secondary commands.
Avoid when
The job is choosing a form value, selecting several values, or browsing a long list.
Required state
Closed trigger state with visible or accessible name.
Accessibility burden
Use an actual button for the trigger when possible.
Common misuse
Using a menu button for long value selection that should be a select, listbox, combobox, or multi-select.

Command palette

UI or UX
UI + UX - Modal command surface
UI guidance
Render a compact dialog-like command surface with a search input, current scope, typed command mode, active result, command metadata, and empty state.
UX guidance
Accelerate expert navigation and repeated actions across a large product while preserving ordinary navigation for novice and low-frequency users.
Good UI
Centered command surface with input, shortcut hint, scope chip, grouped commands, command type labels, and a visible active row.
Bad UI
Huge branded modal that buries the input below decorative content.
Good UX
Keyboard shortcut or visible trigger opens the palette, focus lands in the command input, arrows move the active row, and Enter activates the highlighted safe command.
Bad UX
Palette is the only way to reach important navigation.
Best fit
Users need to traverse a broad product surface quickly.
Avoid when
The app has only a few obvious actions.
Required state
Closed state with discoverable trigger.
Accessibility burden
Use dialog semantics with a clear name and modal behavior when the rest of the page is inert.
Common misuse
Hiding basic navigation behind a keyboard-only palette.
Decision rules
  • Prefer a toolbar when a view or editor needs a persistent strip of related controls such as Undo, Redo, Bold, Align, Filter, Export, and More, and users benefit from one labelled command region rather than scattered buttons.
  • Prefer a button group when two to four visible actions belong to one local workflow moment, such as Save, Continue, and Cancel, and ordinary tab order through each button is clearer than composite toolbar focus.
  • Prefer a menu button when a single named trigger reveals a compact set of secondary commands and those commands do not need to remain visible as a persistent command surface.
  • Prefer a command palette when the command set is broad, searchable, shortcut-driven, product-wide, or includes navigation across distant areas rather than commands for the current view.
  • A toolbar may contain buttons, toggle buttons, menu buttons, separators, and compact inputs, but every control must share the toolbar's current view or selection scope.
  • Do not use a toolbar as primary app navigation; if controls switch destinations, use navigation patterns such as global navigation, side navigation, tabs, or bottom navigation.
  • Do not hide primary task completion in toolbar overflow when a button group, form footer, or dialog action area should make the command visible at the decision point.
  • Use toolbar overflow for lower-priority commands that cannot fit, while keeping current selection, critical safe actions, and stateful toggles understandable before and after overflow.
  • If icon-only toolbar controls appear, give each one a precise accessible name and use tooltips only as supplemental descriptions, not as the sole label.
  • If the toolbar uses one tab stop, implement arrow-key movement, Home and End when useful, disabled-control discoverability, orientation, and focus preservation after activation.
Inspect live examples
Failure modes
  • A row of unrelated buttons is labelled toolbar even though actions affect different objects, routes, and tasks.
  • Keyboard users tab through every toolbar item in a large editor and lose the efficiency that a composite toolbar should provide.
  • Arrow keys move focus but also change a nested slider or select value unexpectedly because nested control keyboard ownership was not defined.
  • A More overflow menu contains the only Save or Submit command for the view, hiding the primary task at the moment users need it.
  • Icon-only controls rely on tooltip text and screen readers hear Button, Button, Button across the toolbar.
  • The toolbar changes selected document state but does not update pressed, disabled, current-selection, or status text after activation.
  • Toolbar controls remain enabled when no object is selected, so users can trigger commands with no visible target.
  • The toolbar is visually attached to the header but actually controls a nested table, creating scope confusion.