A good tooltip is short, optional and tied to one element. It appears on hover or keyboard focus, adds context the screen does not already give, and never carries anything a user needs to finish a task. If removing it would block someone, the content belongs on the screen. This guide covers when to use a tooltip, how it differs from a popover and a product tour, and the copy, timing and accessibility rules that major design systems agree on.
TL;DR
- Use a tooltip for optional context: an icon-only button, a truncated label, an ambiguous control. Never for information needed to complete a task.
- A tooltip is non-interactive text. Anything with links, buttons or rich content is a popover.
- Keep copy to a line or two, in sentence case, with a delay of roughly 300 to 500 ms before it shows on hover and no delay on keyboard focus.
- Meet WCAG 2.2 on hover and focus content: dismissible, hoverable and persistent. Tooltips also have to work without a mouse.
- In a free trial, a tooltip cannot rescue a confusing setup. Fix the flow first, then add tooltips where a small hint removes real hesitation.
Table of Contents
- What a tooltip is, and what it is not
- When to use a tooltip
- Tooltip vs popover
- Tooltips vs product tours
- Write tooltip copy that earns its space
- Timing, placement and size
- Accessibility requirements
- Tooltips inside a free trial
- Get a second pair of eyes on your trial
- FAQ
- Sources
What a tooltip is, and what it is not
A tooltip is a small popup that shows information when an element receives keyboard focus or the pointer hovers over it. That is how the W3C WAI-ARIA Authoring Practices tooltip pattern defines it. Two details matter for design. The tooltip itself never receives focus, and Escape dismisses it.
That definition rules out several things teams call tooltips:
- A box with a "Got it" button is a popover or a coach mark.
- A numbered series pointing at different parts of the screen is a tour.
- A red message under a form field is validation, and it should be visible all the time.
Keeping these apart is the first best practice. Most bad tooltips are one of those other patterns wearing the wrong component.
When to use a tooltip
The design systems of large software companies and agencies say the same thing in different words: a tooltip assists, and it is never required.
SAP's design system puts the principle plainly: a tooltip helps but should never be needed to complete a task. It lists good uses: explaining icon-only actions, clarifying ambiguous UI, revealing truncated text, and adding context without clutter. The CMS Design System, published by the U.S. federal Centers for Medicare & Medicaid Services, adds that tooltips can strengthen an existing message or increase certainty about an interaction, and that they are a last resort for space-constrained interfaces.
Good fits
| Situation | Tooltip content |
|---|---|
| Icon-only toolbar button | A noun or verb phrase naming the action |
| Truncated table cell or file name | The full text |
| Ambiguous control, such as a toggle with a vague label | One sentence on what it changes |
| Metric label in a dashboard | A short definition |
| Disabled-looking state that is actually a permission limit | Better handled with visible text, see below |
Poor fits
Atlassian's guidance is that anything a user must understand, decide on or complete a task with should always be visible. Use labels, helper text or error messaging instead. The same page says to place tooltips only on interactive elements such as buttons, links and menu items, so keyboard and assistive technology users can reach them, and never on disabled elements.
So these do not belong in a tooltip:
- Pricing, limits or plan restrictions the user needs before they commit.
- Required formats for a field (put them in helper text).
- Error explanations.
- Steps the user must follow.
There is also a reason to be sparing. Intuit's content design guidance says tooltips should be the exception, because each one adds friction. If a tooltip is not exactly what the customer needs at that moment, it becomes an annoyance, and a rapid succession of them turns people off. Intuit also warns against using them as a band-aid. A clunky tooltip can signal that the team never worked out whether the problem was content, interaction or product design.
Tooltip vs popover
This is the comparison most readers search for, and the line is clear. Skyscanner's design system describes tooltips as non-interactive, text-only labels shown on hover or focus and dismissed on mouse leave or blur. Popovers are contextual containers for rich, interactive content, triggered by click, tap or focus and dismissed manually.
| Tooltip | Popover | |
|---|---|---|
| Content | Plain text | Text, links, buttons, images, forms |
| Trigger | Hover or keyboard focus | Click, tap or focus |
| Dismissal | Automatic on leave or blur | Manual: close button, Escape, outside click |
| Interactive | No | Yes |
| Touch devices | Poor fit | Works on desktop and mobile |
The touch row is the one teams forget. Hover does not exist on a phone. Skyscanner recommends showing tooltip content in a bottom sheet on touch devices. SAP's Fiori guidance makes a related point: because tooltips are usually mouseover-driven and limited to desktop, they should never hold critical or redundant information.
A quick test: if the content needs a link or a button, use a popover. If the content is a label or one sentence of clarification, use a tooltip. If you are tempted to put a link in a tooltip, Intuit's advice is to avoid it, since links interrupt the workflow and are often unreachable by keyboard or screen reader.
The same logic applies to markup. Putting controls inside other controls produces broken behavior for keyboard and assistive technology users. This reference on interactive content nested inside a button shows why a tooltip should stay plain text rather than hold anything clickable.
Tooltips vs product tours
A tour is a sequence of tooltips. Intuit defines a guided tour as ordered tooltips that demonstrate a new function or task. It recommends three or four tooltips on desktop and one on mobile, and says that if a tour reaches six or more, consider a video tutorial or help article instead.
The practical difference is who starts the interaction.
- A tooltip is pulled by the user. They hover over something unclear and get an answer.
- A tour is pushed by the product. It interrupts, so it has to earn the interruption.
Use a tooltip when the confusion is local to one element. Use a short tour when a new feature has an order of operations that the interface cannot show on its own. Use neither when the real issue is that the first screen asks for too much. We cover that distinction in more depth in our guide to in-app guidance for B2B SaaS free trials.
Write tooltip copy that earns its space
Copy is where most tooltips fail. Take limits from the design systems and apply them consistently.
- Length. Intuit caps a tooltip at three lines, with a header of at most 60 characters and a body of at most 130 characters. Narrow tooltips also read better, so set a max width instead of letting text run across the screen.
- Lead with a verb when introducing a new function, per Intuit. "Filter by owner" beats "This is the owner filter."
- Label unlabeled controls with a noun phrase. Microsoft's Fluent 2 says to use a simple descriptive noun phrase in sentence case with no end punctuation, and to keep tooltip content helpful but non-essential plain text.
- Sentence case, direct wording. The LogRocket design guide recommends concise, direct sentence-case copy.
- No redundancy. If the tooltip repeats the visible label, delete it. SAP's guidance warns against redundant information for exactly this reason.
Before and after
| Weak | Stronger |
|---|---|
| "Click here to learn more about integrations" | "Connect your CRM" |
| "This button lets you export your data to a CSV file" | "Export as CSV" |
| "Seats: the number of seats" | "Users who can edit this workspace" |
| "Warning: you must complete this field" | Move to helper text under the field |
The last row matters most. If your edit is "move it out of the tooltip," that is the best practice at work.
Timing, placement and size
Numbers differ by system, but they cluster.
- Show delay. SAP specifies a delay of 300 to 500 ms before a tooltip appears on hover, and no delay on focus. The delay stops tooltips firing on accidental passes of the cursor.
- Animation. SAP lists 100 to 150 ms to enter and 75 to 100 ms to exit.
- Persistence. SAP says the tooltip must stay visible while hovered or focused, with no auto-dismiss timeout. Material Design 3 says tooltips without required actions should stay on screen long enough to read, and should not block important information or stop someone completing an action.
- Distance. Fluent 2 places a tooltip 4 pixels from its target.
- Contrast and size. The LogRocket guide cites the WCAG 4.5:1 contrast ratio and font sizes of 12px to 24px for readability.
For placement, keep the tooltip adjacent to its trigger, avoid covering neighboring controls, and flip position when it would clip at the viewport edge. Default to above or below the trigger for consistency, so users learn where to look.
Accessibility requirements
Hover-only tooltips exclude keyboard users, screen reader users, and people using magnification. Three standards cover the essentials.
WCAG 2.2 success criterion 1.4.13. Content that appears on hover or focus must be dismissible without moving the pointer or focus, hoverable, and persistent. Persistent means it stays until the trigger is removed, the user dismisses it, or the information is no longer valid. Hoverable means a user can move the pointer onto the tooltip without it vanishing, which matters for anyone using screen magnification.
The APG tooltip pattern. The container uses role="tooltip", and the trigger references it with aria-describedby. The tooltip does not take focus. Escape closes it. It opens on keyboard focus as well as hover.
Atlassian's scope rule. Attach tooltips only to focusable, interactive elements. A tooltip on a plain icon or a disabled button is invisible to keyboard users. If a button is disabled, explain why in visible text next to it.
A short checklist for review:
- Tab to every trigger. Does the tooltip appear?
- Press Escape. Does it close without moving focus?
- Hover the trigger, then move onto the tooltip. Does it stay?
- Check contrast at 4.5:1.
- Open the page on a phone. Is the information reachable at all?
If step 5 fails, the content is probably critical enough to be on the screen.
Tooltips inside a free trial
In a trial, every hint competes with the user's goal: reach a first result before attention runs out. That changes how you apply the rules above.
Fix the path before you annotate it. If users abandon during setup, tooltips on setup fields treat a symptom. Ask whether the field is needed before the first result at all. Our product onboarding checklist and onboarding flow examples both focus on the route from signup to a first result.
Keep money information visible. Plan limits, seat counts and the total at checkout are decision information. By the Atlassian standard above, they belong on the page, not behind a hover.
Use tooltips for the second pass. Once the main path works, tooltips are useful for secondary controls, such as an icon in a dense toolbar, that a new user will meet on day two or three.
Test with real sessions. Hover behavior is hard to judge in a design review. Watching new users reveals which tooltips they read and which they ignore or trigger by accident. Our guide to in-app usability testing walks through how to run that.
Remove what does not help. Treat each tooltip as a small cost, as Intuit does. If a tooltip does not change what a user does, cut it.
Our view on tooltips in a trial
When we go through a trial as a buyer, with a stopwatch and a screenshot of every step, tooltips show up a lot. Most of them sit on a screen that has a bigger problem: setup that comes before any result, or an upgrade prompt that lands before the first win. The tooltip is usually the team's attempt to explain the problem rather than remove it.
Our approach is to tie each change to documented user behavior. So before we write a hint, we ask what the user was trying to do, where they stopped, and whether a clearer label or a shorter path would make the hint unnecessary. When a tooltip is still the right answer, we keep it short, optional and keyboard-reachable.
That is the same discipline we applied in setup work like the flow for new creators at Supliful. The goal is to get people to a first result sooner, not to add more guidance on the way there. We think a good tooltip is a sign that the rest of the interface is already doing its job.
Edijs
Get a second pair of eyes on your trial
If your trial gets sign-ups but too few paying customers, tooltips are rarely the lever. The loss usually happens earlier or later: in setup, at the first upgrade prompt, or at checkout. Through our Trial to paid service, we go through your trial as a user, map where people leave between sign-up and payment, and recommend what to fix first and why.
If you would rather see how we work before talking, our Product Teardown Examples show what each review looks at. You can also see the full range of consulting services.
FAQ
What is the difference between a tooltip and a popover?
A tooltip is non-interactive, text-only and appears on hover or focus, then disappears when the user leaves. A popover holds richer, interactive content such as links or buttons, opens on click or tap, and is dismissed manually. If the content needs an action, use a popover.
When should I use a tooltip instead of a product tour?
Use a tooltip when one element is unclear and the user can ask for help by hovering or focusing it. Use a tour only when a new feature has an order of steps the interface cannot convey. Intuit suggests three or four tooltips per tour and a video or help article for six or more.
How long should tooltip text be?
Short enough to read in a glance. Intuit's limits are three lines, a 60-character header and a 130-character body. For icon-only controls, a noun phrase of one to three words is usually enough, in sentence case without end punctuation.
Can I put a link or button inside a tooltip?
No. Tooltips are plain text, do not receive focus, and disappear on blur, so keyboard and screen reader users cannot reach anything inside. Intuit advises against links in tooltips for the same reason. Use a popover, or put the link on the page.
Do tooltips work on mobile?
Not as hover tooltips, because touch screens have no hover state. Skyscanner recommends showing the content in a bottom sheet on touch devices. If the information is needed to proceed, show it on the screen for every device.
Sources
- Tooltip Pattern, W3C WAI-ARIA Authoring Practices
- Tooltip, CMS Design System
- Tooltip overview, SAP Design System
- Using Tooltips, SAP Fiori Design System
- Tooltip usage, Atlassian Design System
- Tooltips, Intuit Content Design
- Popovers vs Tooltips, Skyscanner Design System
- React Tooltip, Fluent 2 Design System
- Tooltips accessibility, Material Design 3
- Understanding Success Criterion 1.4.13, W3C WCAG 2.2
- Designing better tooltips for improved UX, LogRocket Blog