Toolbar
A toolbar is a horizontal strip of controls that act on the content beside or below it. It stays in view while you work, so formatting and undo are always one click away.
<div role="toolbar">Also called Formatting bar, Rich text toolbar, Action bar.
Quarterly update for the product team. Edit the paragraph below.
Toggle bold, italic, or underline on the strip. Tab lands on the toolbar once, then arrow keys move between controls.
For designers
A toolbar is the strip that stays attached to the thing you are changing. Google Docs keeps bold across the top of the page. Figma pins align and distribute above the canvas. The pattern works when every control in the row shares one target: the selection, the paragraph, the artboard.
Notion's editor toolbar grows when you select text and shrinks when you click away. That coupling is the point: the strip only shows tools that apply to what is selected right now.
The cost is horizontal space. Each icon added is width taken from the content below. Count what people reach for in the first week, put that on the strip, and move the rest behind a chevron menu at the end. A toolbar with twenty icons is a junk drawer with good alignment.
When to use a toolbar
Use a toolbar when
- Several controls all act on the same editor, canvas, or selection
- People need bold, align, undo, or zoom without leaving the surface they are editing
- The strip can stay visible or sticky while the content scrolls underneath
Reach for something else when
- One primary action and a few rare alternates are enough, with a clear default. Use a split button instead.
- The list is long and only some items apply at any moment. Use a menu instead.
- The controls navigate the app rather than changing the content in front of you. Use tabs instead.
- Every control fits in a single overflow menu without hurting daily work. Use a menu instead.
Variants
Full
Compact
A full strip above the canvas. A compact row for tables and comment fields where height is tight.
Full. Toggles, separators, icon buttons, and a primary action like Publish at the end. The demo above is this layout.
Compact. Icon-only tools at icon-xs height for table cells, comment fields, and inline editors. Drop labels and keep tooltips.
Sticky. The same strip with position: sticky on the editor wrapper so formatting survives scroll. Pair with a shadow when the content moves underneath, so the strip reads as floating above the text.
How to build a toolbar
Give the strip role="toolbar" and an accessible name that says what it formats. Inside, use toggle buttons with aria-pressed for modes that stay on, and ordinary buttons for one-shot actions like undo.
<div role="toolbar" aria-label="Text formatting">
<button type="button" aria-pressed="true" aria-label="Bold">B</button>
<button type="button" aria-pressed="false" aria-label="Italic">I</button>
<button type="button" aria-pressed="false" aria-label="Underline">U</button>
<span role="separator" aria-orientation="vertical"></span>
<button type="button" aria-label="Insert link">Link</button>
<button type="button">Publish</button>
</div>
Tab lands on the toolbar once. Left and Right arrows move between controls without leaving the strip. Space toggles a pressed button; Enter activates a plain button. Disabled tools stay in the tab order but skip arrow navigation when they cannot apply to the current selection.
Icon-only buttons need aria-label values that name the action, not the icon shape. Teams often rebuild this as twelve separate tab stops, which doubles the key presses for anyone formatting a sentence. The roving tabindex model is worth the implementation time on any strip with more than four items.
Edge cases
Overflow. When the strip wraps on a narrow screen, keep groups intact. A separator should not sit alone on its own line.
Selection-dependent tools. Disable link when nothing is selected, but explain why in the tooltip. A silent disabled icon reads as broken.
Reduced motion. Tooltips and pressed-state fills can snap under prefers-reduced-motion: reduce. The toolbar itself has nothing to animate.
Common questions
- Toolbar or a row of buttons?
- A toolbar groups controls that share one target and one keyboard model. A row of page actions, like Export and Share on an invoice header, is usually separate buttons, because they act on the page, not on a paragraph inside it.
- How many items fit on a toolbar?
- Roughly eight to twelve before people stop scanning. Past that, group with vertical separators and move rare actions into a menu at the end. Google Docs keeps the daily formatting tools visible and hides the rest behind an arrow.
- Toggle buttons or a segmented control?
- Use toggle buttons when more than one mode can be on at once, like bold and italic together. Use a segmented control when exactly one alignment or view mode is true. The segmented control page covers the single-select case.
- Should tooltips show shortcuts?
- Yes on icon-only tools. Put the shortcut in the tooltip, not only in documentation. After the first tooltip in a group opens, show the rest immediately so scanning the strip feels quick.
- One tab stop or one per button?
- One tab stop on the toolbar, then arrow keys between items, is what the WAI-ARIA Authoring Practices recommend for toolbars. Tab out of the strip to reach the content. Home and End jump to the first and last control.
- What about mobile?
- Shrink to the four tools people use in the first minute, then put the rest in a bottom sheet or an overflow menu. A full desktop strip across a phone keyboard leaves no room to see what you are editing.
Last reviewed 27 AUG 2026