What Is a Tooltip, and When Should You Use One?

In short

A tooltip is a small, transient label that appears on hover or focus to explain an element, typically an icon button, and disappears when the pointer moves away. Use one to name an icon-only control or to add brief, non-essential context. Do not put essential information, links or interactive content in a tooltip, because it is invisible on touch screens and difficult for keyboard and screen-reader users unless carefully built. For anything a user must read, use a visible label, inline help text, or a popover that opens on click.

A tooltip is a small text label that appears when the pointer rests on an element, or when the element receives keyboard focus, and disappears when it leaves. Its classic use is naming an icon: hover over the funnel, see "Filter". It is transient, non-interactive, and supplementary. If the tooltip never appeared, the interface should still be usable.

That last property is the test for whether something is a tooltip at all. Content that must be read, that contains a link or a button, or that stays open until dismissed is not a tooltip; it is a popover, a hint or a dialog, and it should be designed as one.

Naming icon-only controls. Toolbars, action rows and compact interfaces use icons because labels would not fit. A tooltip supplies the name for anyone unsure. This is the primary legitimate use, and even here the tooltip is a fallback for a visible label, not a replacement.

Brief, optional context. The full value behind a truncated cell, the date behind "3 days ago", the exact figure behind a rounded one. Useful, and safely omitted for those who cannot see it.

Keyboard shortcuts. "Save (Ctrl+S)" on hover teaches the shortcut to people who would use it, without cluttering the label.

Where tooltips fail

Touch screens. There is no hover on a phone. A long-press sometimes shows a tooltip and sometimes triggers something else; most users never discover it. Any information that exists only in a tooltip is invisible to the majority of visitors on most sites.

Keyboard and screen-reader users. A tooltip that appears only on mouse hover is unreachable by keyboard. A tooltip that is not associated with its trigger through the accessibility tree is never announced by a screen reader. Building a tooltip that works for both requires focus handling, an aria-describedby association, an escape key to dismiss, and content that remains hoverable so users with magnification can read it. WCAG 1.4.13 specifies these; most tooltip implementations meet none of them.

Discoverability. A tooltip is invisible until someone hovers over exactly the right spot. Users do not sweep the screen with the pointer looking for hidden explanations; if an element needs explaining, most users will not learn the explanation.

Essential content. Form field requirements, error explanations, pricing conditions and terms placed in a tooltip are placed where a large share of users will never see them. This is the most damaging misuse and a frequent cause of form abandonment.

Long content. A tooltip is a phrase. A paragraph in a tooltip is a popover with the wrong behaviour.

Tooltips, popovers, hints and dialogs

Tooltip: hover or focus, short text, no interaction, disappears on leave.

Popover: opens on click or tap, can contain formatted text, links and controls, stays until dismissed, works on touch. The right choice for anything more than a label.

Inline hint or help text: always visible, beside or beneath the element. The right choice for form requirements, definitions and anything the user must know.

Dialog: modal, for content that needs the user's full attention or a decision.

Most tooltip misuse is a popover or an inline hint wearing the wrong component.

Trigger on hover and on focus, and dismiss on leave, blur and Escape.
Associate it with the trigger via aria-describedby, or use aria-label on the trigger if the tooltip merely names it.
Delay slightly on hover, around 300 to 500 milliseconds, so tooltips do not flicker as the pointer crosses the screen; show immediately on focus.
Keep it short. A name or a phrase; no formatting, no links.
Do not cover the trigger or anything the user is looking at; position it adjacent and keep it within the viewport.
Let it be hovered so the pointer can move onto it without dismissing it, which magnification users need.
Never make it the only path to information. If a control is icon-only, consider whether it should have a visible label after all; on any navigation or toolbar where space allows, it should.

The decision

If the information is essential, put it on the screen. If it is a name for an icon, a tooltip is the accepted fallback, built accessibly. If it is more than a phrase, or needs to work on touch, use a popover. Interfaces that follow that order need fewer tooltips than their designers expect, and the ones that remain are the harmless kind. If you would like an interface reviewed for information hiding in places users cannot reach, book a call; it is a common finding in design audits.

Common questions

What is the difference between a tooltip and a popover?

A tooltip appears on hover or focus, holds a short non-interactive label, and disappears when the pointer leaves. A popover opens on click or tap, can contain formatted text, links and controls, stays open until dismissed, and works on touch screens. Anything longer than a phrase or needing interaction should be a popover.

Do tooltips work on mobile?

Not reliably. Phones have no hover, and long-press behaviour varies and is rarely discovered. Information placed only in a tooltip is effectively invisible to touch users, which on most sites is the majority. Use visible labels, inline help text or click-to-open popovers for anything mobile users need.

Are tooltips accessible?

Only when built carefully: shown on keyboard focus as well as hover, associated with the trigger through aria-describedby so screen readers announce them, dismissible with Escape, hoverable so magnification users can read them, and never the sole source of essential information. Most default implementations meet few of these requirements.

Should form field instructions be in a tooltip?

No. Requirements such as password rules, format expectations and why a field is needed should be visible help text beside or beneath the field, where every user sees them before typing. Tooltips hide instructions from touch users and many keyboard users and are a common cause of form errors and abandonment.

How long should a tooltip be?

A word or a short phrase: the name of an icon, a keyboard shortcut, a full value behind a truncated one. If it needs a sentence or more, it is not a tooltip; move the content to inline help text or a popover that opens on click and stays open.

UXAccessibilityproduct design