Get startedanimationsComponentsThemes

Components

Toolbar

Toolbars group related actions in a docked or floating container.

Usage

Toolbar groups related actions in a docked or floating container. It is a composition wrapper: put Button, IconButton, an image, or another appropriately labelled custom control inside it. The toolbar does not duplicate the action’s state, tooltip, or keyboard behavior.

Docked toolbar

Use a docked toolbar at the bottom of the current app surface. It can be paired with a FAB when the FAB represents the primary action; the screen owns the placement and the action state.

Document canvas

The docked toolbar stays attached to the bottom of this surface.

Last action: None

Combining toolbars

Two toolbars can coexist when they serve separate responsibilities: this example uses a floating selection group over a docked document group. Keep enough space between the groups, and collapse one group into overflow in compact layouts.

Document canvas

Keep each toolbar responsible for a distinct action group.

Floating toolbar

Use a floating toolbar when actions should remain visible in context. This example focuses on the default horizontal floating arrangement.

Vibrant toolbar

Use color="vibrant" when the toolbar needs the expressive color treatment. This is a separate visual choice from the floating arrangement.

Flexible slots

Toolbar is only a container, so its slots can hold buttons, icon buttons, images, or custom content. A filled button or filled icon button can give one action more emphasis without changing the toolbar itself.

Vertical toolbar

Vertical floating toolbars suit spacious layouts with a secondary action group. Material 3 does not recommend this orientation in compact layouts; prefer an overflow action when width is limited.

Quick actions

Use this spacious arrangement for contextual actions.

Overflow actions

Pass an actions model when the toolbar should manage visibility for you. maxVisible keeps the first actions visible and moves the rest into a generated menu; set pinned: true on an action that must remain visible. The example uses several editing actions so the generated menu has meaningful content.

The generated menu uses automatic placement by default: it opens below a horizontal toolbar in the upper half of the viewport and above it in the lower half; vertical toolbars use the equivalent right/left rule. Use morePosition to force a specific placement when needed.

Responsive overflow

Use responsive when the visible action count should follow the toolbar’s actual width instead of a fixed maxVisible value. Resize the example to see actions move into or out of the generated overflow menu.

Resize this container to move actions into the overflow menu.

Custom overflow trigger

The generated menu stays the same when its trigger needs a different treatment. Use renderMore, moreTemplate, or the equivalent framework-specific slot with a custom button to replace the default icon button while keeping the automatic action management.

Guidelines

  • Toolbars are 64dp high by default; use IconButton size="small" for the 48dp toolbar slots and keep every interactive child at or above that target.
  • Docked toolbars use 16dp edge padding and 8dp minimum spacing between actions; compact widths distribute the actions evenly.
  • Floating toolbars use compact 8dp internal padding and 4dp between actions.
  • Keep a horizontal floating toolbar at least 16dp from surrounding edges and a vertical floating toolbar at least 24dp away.
  • Docked toolbars belong at the bottom of the surface and should not be shown simultaneously with a navigation bar.
  • Avoid multiple toolbars in compact layouts. Use overflow when actions do not fit and keep the overflow action in its logical position in RTL layouts.

Accessibility

The root exposes role="toolbar". Provide accessibleLabel, or connect an external heading with aria-labelledby, so assistive technology can identify the action group. In actions mode, the generated trigger exposes its menu relationship and the menu items reuse each action’s accessible label. In composition mode, children own focus, activation, pressed state, and labels. In particular, an IconButton should always receive a meaningful label.

This wrapper intentionally does not implement roving focus or arrow-key navigation. If a product needs a composite keyboard model, use a dedicated interaction pattern around the child controls rather than assuming that every toolbar is a single composite widget.