What Is a Hover Card?
A hover card is a small preview panel that appears when a user hovers over a link, name, or thumbnail, showing rich context without requiring a click. You see them when hovering a username reveals a profile summary, or a link previews its destination page. Hover cards let people glance at extra information, such as an avatar or short bio, and decide whether to click through. Because they depend on hovering, they must be designed carefully so keyboard and touch users, who cannot hover, are not left out.
- What it is
- A preview panel shown on hover, offering context without a click
- Also called
- Hover card, preview card, or rich tooltip
- Common uses
- Profile previews, link previews, product quick views, glossary definitions
- Hover content rule
- Content shown on hover or focus must be dismissible, hoverable, and persistent (WCAG 2.2)
- Accessibility
- Must also work on keyboard focus and be dismissible; hover alone excludes many users (WCAG 2.2)
What a hover card is #
A hover card is a floating panel of preview content that appears when a user points at, or focuses on, an element such as a link, a person's name, or an image thumbnail. Unlike a plain tooltip, which usually shows a short line of text, a hover card can display richer content: an avatar, a heading, a short description, a few stats, and sometimes small actions. The idea is to let people preview what is behind a link or name and decide whether to click, without leaving the page they are on. Social platforms use them to show a mini profile when you hover a username; documentation sites use them to preview a linked article; stores use them for quick product glances. Done well, a hover card reduces unnecessary clicks and back-navigation, letting users stay in flow. Designing these previews so they inform rather than annoy is part of the interface craft on our /services/ui-ux-design page.
Hover card versus tooltip #
Hover cards and tooltips are cousins, but they serve different jobs. A tooltip is a small, text-only hint, typically a word or short phrase, that clarifies an icon or control, such as explaining what a gear button does. It is lightweight and appears quickly. A hover card is a larger, richer container that presents structured content, an image, a title, a summary, maybe a call to action, so it functions more like a mini preview than a hint. Because it holds more, it usually appears after a short delay and often lets the user move their cursor into it to interact, whereas a tooltip vanishes the moment you move away. Choosing between them comes down to how much context you need to show: a label or clarification calls for a tooltip, while a genuine preview of a destination or entity calls for a hover card. Matching the right pattern to the need is central to the layout decisions on our /services/web-design page.
When hover cards work well #
Hover cards shine when a link or name points to something a user might want to size up before committing to a click. Previewing a linked article's title and summary helps readers decide if it is worth the detour. Showing a mini profile on a username, name, avatar, and a stat or two, gives social context without a page change. In a store, a quick-view card can surface a product image, price, and rating so shoppers browse faster. Glossary or citation previews let readers check a definition or source in place. In each case the card saves a round trip and keeps people in flow. The pattern works best on content-rich, desktop-oriented interfaces where hovering is natural and the extra context genuinely aids a decision. It is less suited to simple sites where a click is cheap and the added complexity is not worth it. Weighing that trade-off is exactly the kind of judgement we bring on our /services/web-design page. On content-heavy desktop sites this convenience adds up, saving needless round trips as users decide which links are worth opening.
Building a hover card in code #
A basic hover card can be built with HTML and CSS by pairing a trigger element with a hidden panel that reveals on hover and focus. Crucially, using focus as well as hover means keyboard users are included. Here is a minimal, accessible pattern.
<span class="hovercard">
<a href="/profile/jane" class="hc-trigger">@jane</a>
<div class="hc-panel" role="dialog" aria-label="Profile preview">
<img src="/avatars/jane.jpg" alt="" width="48" height="48">
<strong>Jane Doe</strong>
<p>Product designer. 1.2k followers.</p>
</div>
</span>
<style>
.hc-panel { visibility: hidden; opacity: 0;
transition: opacity .15s .2s; /* .2s open delay */ }
.hovercard:hover .hc-panel,
.hovercard:focus-within .hc-panel {
visibility: visible; opacity: 1; }
</style>The problem with hover-only interactions #
The biggest weakness of a hover card is right in its name: hovering is a mouse behavior, and huge numbers of people do not use a mouse. Touchscreen users on phones and tablets have no hover state at all, so a pure hover card is simply invisible to them or fires awkwardly on tap. Keyboard users navigate by focus, not a cursor, and screen-reader users may never trigger a hover event. If important information or actions live only inside a hover card, those users are excluded. This is why accessibility guidance treats hover-only content with caution and requires alternatives (WCAG 2.2). The safe approach is to treat the hover card as an enhancement, a convenience for mouse users, while ensuring the same information is reachable another way, such as on the destination page itself or via focus and tap. Designing so that no one is locked out is a core commitment reflected on our /services/ada-compliance page.
Accessibility requirements for hover cards #
To be accessible, a hover card must satisfy a few specific requirements. First, it should appear on keyboard focus as well as mouse hover, so users tabbing through a page can reach the content, which the focus-within pattern in the earlier example provides. Second, the content must be dismissible without moving the pointer, typically by pressing Escape, and it should not vanish the instant the cursor leaves, so users can move into the card to read or click it; this hoverable-and-persistent behavior is required by WCAG 2.2 for content shown on hover or focus. Third, never place essential information or the only path to an action solely inside the card, since touch users cannot hover. Fourth, ensure adequate color contrast and that the card does not obscure the content the user needs. Finally, give assistive technology appropriate roles and labels. Building these behaviors in from the start, rather than retrofitting them, is part of the standards-led work on our /services/ada-compliance page. Getting this right separates a helpful hover card from one that traps keyboard and touch users.
Common mistakes with hover cards #
A frequent mistake is making the card appear instantly on hover, so it flashes annoyingly as the cursor merely passes over links; a short open delay of around 200 to 400 milliseconds fixes this. Another is making the card vanish the moment the pointer leaves the trigger, which stops users from moving into it to click a button or read fully. Overloading the card with too much content turns a quick glance into a cluttered mini page and slows the interaction. Relying on hover alone, with no focus or touch alternative, excludes keyboard and mobile users entirely. Poor positioning, where the card is clipped by the screen edge or covers the very link the user is reading, frustrates rather than helps. And loading heavy previews on every hover can hurt performance. Each of these turns a helpful convenience into a nuisance. Spotting and correcting them on a live site is a common outcome of our /free-website-audit. Reviewing these behaviours on real devices, rather than assuming they work, catches the large majority of hover-card problems well before visitors ever encounter them.
Best practices and our recommendation #
Use a hover card only where a genuine preview aids a decision, and keep its content focused: a title, a short summary or profile, and at most one clear action. Add a short open delay so it does not flash, and make it persist and be hoverable so users can move into it, dismissible with Escape, and reachable by keyboard focus, not just mouse hover. Position it so it never covers the trigger or gets clipped off-screen. Above all, treat it as an enhancement: ensure the same information is available to touch, keyboard, and screen-reader users through the destination page or other means, so no one is left out. Test on a phone, with a keyboard, and with a screen reader before shipping. Handled this way, hover cards speed up browsing without excluding anyone. If you want previews that are helpful and inclusive, our /services/ui-ux-design and /services/web-design teams design them to work for every visitor.
Testing hover cards before you launch #
Because hover cards behave differently across devices and input methods, testing them properly before launch prevents most of the problems that frustrate users. Check the mouse experience first: does the card appear after a sensible delay rather than flashing, stay visible long enough to read, and let you move the pointer into it to click without vanishing? Then test with a keyboard alone, tabbing to the trigger to confirm the card appears on focus and can be dismissed with Escape. Crucially, test on a real phone, since touchscreens have no hover, to make sure the information is still reachable another way. Verify with a screen reader that the content is announced sensibly, and check that the card is never clipped off-screen or covering the very link you are reading. Running through these checks catches issues that look fine on a designer's desktop but break for real visitors. A quick, structured review of an existing site's interactive elements is something you can begin with our /tools/website-grader.
FAQ
What is a hover card?
A hover card is a small preview panel that appears when a user hovers over or focuses on a link, name, or thumbnail. It shows rich context, such as an avatar, short bio, stats, or a page preview, without requiring a click, letting people glance at extra information and decide whether to click through.
What is the difference between a hover card and a tooltip?
A tooltip is a small, text-only hint, usually a word or phrase clarifying a control. A hover card is larger and richer, holding structured content like an image, title, summary, and sometimes an action, so it works as a mini preview. Use a tooltip for a label and a hover card for a genuine preview.
Do hover cards work on mobile?
Not naturally, because touchscreens have no hover state. On mobile a pure hover card is invisible or fires awkwardly on tap. That is why hover cards should be treated as an enhancement for mouse users, with the same information reachable another way, such as on the destination page, so touch users are never excluded.
Are hover cards accessible?
They can be if built correctly. They must appear on keyboard focus as well as hover, stay visible long enough for users to move into and read them, be dismissible with Escape, and never hold essential information only reachable by hovering. Meeting WCAG 2.2 rules for hover and focus content keeps them inclusive.
Why does my hover card flash annoyingly?
Usually because it opens instantly as the cursor passes over links. Adding a short open delay of roughly 200 to 400 milliseconds means the card only appears when the user pauses deliberately, not when they are merely moving the mouse across the page, which removes the distracting flicker.
When should I use a hover card?
Use one where a preview genuinely helps a user decide whether to click, such as showing a linked article's summary, a profile on a username, or a quick product view in a store. Avoid it on simple sites where a click is cheap, and never make it the only way to reach important content.
How Local Web Advisor checks this for you
Is your own website getting web design right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web design and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?