Tooltips and popovers without the nagging

A tooltip is the smallest UI primitive that can ruin a product. Get it wrong and your interface feels nagging, condescending, and unsure of itself, every icon needs a translation, every input needs a coach, every button needs justification. Get it right and the tooltip disappears, surfacing only when the user actually needed it.

Popovers are the same problem one step up. They're the surface you reach for when a tooltip is too small and a modal is too rude. Most teams pick the wrong one and never go back to fix it.

Tooltip vs popover vs modal

Three surfaces, three jobs. Picking the wrong one is the entire problem.

• Tooltip: a small label that appears on hover or focus. Read-only, no interaction inside it, dismissed when the cursor leaves. Use for icon labels, keyboard shortcuts, truncated text.
• Popover: a floating panel anchored to a trigger. Can hold interactive elements, sub-controls, secondary info. Persists until dismissed. Use for filter menus, form helpers, profile cards.
• Modal: a centered overlay that takes the whole screen's attention and blocks the page behind it. Use only when the user must decide before continuing.

When tooltips help

Tooltips earn their slot in exactly three situations.

1. Naming icon-only controls

An icon-only button (a paperclip, a trash can, a download arrow) needs a label for users who don't know what it does and for screen readers either way. A tooltip on hover plus an aria-label covers both.

2. Showing keyboard shortcuts

Hovering a button reveals its keyboard shortcut, ⌘K, ⇧S. This is the single most universal pattern in modern productivity apps. Linear, Notion, Figma, Raycast, every one of them does it. Power users learn the shortcuts; new users get a quiet reminder.

3. Explaining truncated content

A long filename, a clipped email, a numeric ID with no visible label. A tooltip lets users see the full string without expanding the layout. Don't tooltip readable text; you're stating the obvious.

When tooltips backfire

1. 01Captioning a labeled button. "Save" doesn't need a tooltip that says "Save your work." Trust the label.
2. 02Hiding critical info. Anything the user must know to make a decision shouldn't require a hover. Mobile users can't hover. Keyboard users can't hover. Hide help; don't hide content.
3. 03Tooltips on mobile. Hover doesn't exist on touch. If your product is mobile-first, design without tooltips and let labels carry the weight.
4. 04Delays that feel like bugs. A tooltip that takes 1.5 seconds to appear reads as a bug, not a feature. Standard delay is 300–600ms on hover-in, near-instant on focus.
5. 05Tooltips inside tooltips. If your tooltip needs a tooltip, you needed a popover.

When popovers win

Popovers replace small modals about half the time, and the page is calmer for it. Reach for one when you need interactive content that's scoped to a trigger, a filter button opens its filter controls, a user avatar opens a quick profile card, a + button opens a small create menu.

The mental model: a popover is a tooltip that's grown up. It can hold a form, a list, even another button. But it still belongs to its trigger, dismisses on outside click, and never takes the user out of context.

The anatomy of a popover that feels right

• Anchored to the trigger. No floating in space. Floating UI, Radix Popover, and Headless UI all solve placement correctly out of the box.
• Dismisses on outside click and Escape. Both. Skipping Escape breaks keyboard users; skipping outside click feels sticky.
• Returns focus to the trigger on close. The user's keyboard focus shouldn't get lost in the page.
• Has a max width and a max height, with internal scroll if needed. A popover that grows to half the screen has stopped being a popover.
• Animates in 100–150ms, not 300. Long animations on small surfaces feel slow.

Accessibility, briefly

Tooltips need role="tooltip" and have to be reachable on keyboard focus, not just mouse hover. Popovers need a role="dialog" if interactive, focus trap if they contain a form, and an accessible label. Use Radix, Headless UI, or Ariakit, they solve this correctly. Hand-rolled popovers almost always ship with accessibility bugs, and the bugs are invisible until a screen-reader user shows up.

An audit you can do in an hour

Open your product. Hover every icon. For each tooltip that appears, ask: would removing this break anything? If the answer is no, kill it. The remaining tooltips are the ones earning their slot. Most teams cut 40–60% of their tooltips on the first pass and the UI gets quieter and more confident.

Frequently asked

Should every icon button have a tooltip?

Every icon-only button, yes. Every button with a visible text label, no. The tooltip duplicates the label and reads as nervous. Trust your labels.

Tooltip vs label, which wins?

Label, always, if you have room. A visible label is faster to scan than a hover-only one, works on mobile and keyboard, and doesn't depend on user discovery. Use tooltips only when the label genuinely won't fit.

How long should a tooltip take to appear?

300–600ms on hover-in is the standard. Instant on keyboard focus. Faster than 300ms and tooltips fire when users are sweeping the cursor across the screen; slower than 600ms and discoverability suffers.

When is a popover better than a modal?

When the user isn't making an irreversible decision and the action is scoped to one part of the page. Filter menus, color pickers, profile cards, quick edits, all popover territory. Reserve modals for confirmation, sign-in walls, and full forms.

Ship one

The interaction entry in the directory has tuned prompts for tooltips and popovers built on Radix, with the right delays, animation curves, and accessibility wiring already encoded. Pair with the modals entry, the three surfaces are decided together, and shipping them together prevents the most common scope-creep mistake, modals where popovers belonged.