Prepared Docs

Prepared Docs

⌘K

    Loading navigation…

User

  1. Components
  2. Icon Button
  3. Usage

Icon Button

Usage

Overview

IconButton saves horizontal space by exposing an action as a single glyph with no visible label. It belongs in toolbars, table rows, and map or media overlays where a labeled button would wrap or crowd the surface. Because glyphs alone rarely carry meaning for novice operators or assistive technology, every IconButton pairs with a descriptive accessible name and a tooltip that surfaces the outcome. Reserve the pattern for universally taught actions (play, mute, expand), repeated row controls (edit, delete on a row), and density-critical contexts where the label is redundant to adjacent text.

When to use

  • Toolbars and table rows where text labels would wrap or crowd.
  • Media and map controls where industry-standard glyphs carry meaning (play, mute, expand, center).
  • Repeated actions in lists where the row content disambiguates the icon (editing "Incident 42" vs. editing "Incident 43").

When not to use

  • Primary page commits without adjacent explanation—use a labeled Button.
  • Actions operators see rarely enough that they can't learn the iconography. Use text.
  • Split primary-plus-menu patterns—use SplitButton.
  • Icon-only two-state toggles—prefer IconToggle. Non-link IconButton can inherit Button's toggle props for sustained press when a labeled button is the wrong density.

Types

ButtonType semantics mirror Button: at most one Primary icon action per region; Destructive for delete or remove; Critical sparingly in high-attention workflows. Default to Secondary inside toolbars—the icons are strong enough signal on their own.

Shape

IconButton ships with the standard icon-button corner radius by default across every ButtonType. Pass the boolean pill prop to opt in to a fully rounded (pill / circular) border radius for floating toolbars and FAB-style controls (e.g. the staff panel toggle). Combine with cornerStyle={ComponentCornerStyle.Sharp} to override back to square corners when a brand or layout requires it.

Content guidelines

  • Tooltip and aria-label describe the outcome, not the glyph: "Mute microphone", "Open incident in new tab"—not "Microphone icon" or "Arrow icon". Localize with formatMessage.
  • Reuse one icon per action across the product. The same glyph for "Analytics" or "Delete" everywhere is a small detail with outsized navigation cost when it's wrong.
  • Keep tooltips short enough to fit on narrow viewports without wrapping awkwardly.

Behavior and states

  • Tooltips. Appear on focus as well as hover so keyboard users see the label. Delay the tooltip on hover; show it immediately on focus.
  • Disabled. Surface the blocker in the tooltip when it isn't obvious ("Sign in to access" rather than just greying the control).
  • Loading. In-button spinners must not remove the focus outline or the accessible name.

Best practices

Do

  • Use the small size in dense tables while preserving a minimum touch target on tablets.
  • Order groups logically (edit before delete) and use separators when clusters differ.
  • Keep tooltip copy in the same voice as the rest of the product.

Don't

  • Rely on color alone to distinguish icons. Shape and label must differ.
  • Stack many ambiguous glyphs in a row. Move the extras into Menu.
  • Ship an icon-only button without an accessible name. Screen reader users land on "button" with no context.

Accessibility

Focusable, named, and operable by keyboard; tooltips on focus; contrast that holds in both themes. See Accessibility for the full contract.

Related Components

  • Button for text-first actions.
  • Toolbar for floating icon-action strips.
  • Tooltip for the supplementary copy rules.
  • Icon toggle for icon-only two-state toggles.

Previous

Accessibility / Form Integration

Next

Icon Button / API and Development

On this page

Overview
When to use
When not to use
Types
Shape
Content guidelines
Behavior and states
Best practices
Accessibility
Related Components