How do you add a hover effect to a CSS button?
Write a base rule for the button, add a :hover rule that changes only the properties you care about, and put a transition on the base rule so the change animates both ways.
That’s the whole mechanism, and every effect further down is a variation on it.
- Style the resting state with background color, text color, padding and border radius.
- Put the transition on that same rule and name each property you plan to change.
- Add a
:hover rule containing only the values that differ. - Test it with a mouse, then again with the Tab key.
.btn {
background-color: #1d4ed8;
color: #fff;
transition: background-color 200ms ease-out, transform 200ms ease-out;
}
.btn:hover {
background-color: #1e40af;
transform: translateY(-2px);
}
The transition belongs on the base rule, not on :hover. If it only lives in the hover rule, the button eases in and then snaps back on exit, because the resting state has nothing to animate with.
A lot of developers hit this one when they copy a snippet and move a line.
web.dev’s CSS learning module describes the transition shorthand as property, duration, timing function and delay. The property is whatever should animate, like background-color or transform, and you separate several with commas. The duration is the first time value in the shorthand, per MDN Web Docs. For the timing function you pick ease-out, ease-in-out or a custom cubic-bezier() curve, and the delay is the second time value. Buttons rarely need a delay.
Name the properties instead of writing transition: all. The all keyword also animates anything that changes later, like a width set by a media query, and you end up with motion nobody planned.
How long should a hover transition last?
150ms to 300ms suits most buttons. Under that range it reads as a flicker, and past it the button starts to feel like it’s trailing the pointer.
Material Design’s motion guidance says to scale duration with the distance an element travels and its size, not to fix one value for everything. A button that only changes color moves nowhere, so it sits at the fast end.
For hover, ease-out usually feels more responsive than ease-in-out, since the change starts at full speed the moment the pointer arrives.
Transition or @keyframes for hover effects?
Use a transition for a two-state change and @keyframes for anything with several steps or a loop, like a pulse.
A transition reverses smoothly if the pointer leaves halfway. An animation attached to :hover has no way back. When hover ends, the animation is removed and the button jumps to its resting style.
That’s why simple color and lift effects stay on transitions, while looping effects built with keyframe animations need a plan for the exit.
Which states should a button hover style be paired with?
Pair every :hover rule with :focus-visible, and give :active its own look.
Hover responds to a pointer resting over the button, so it only exists for mouse and trackpad users. :focus-visible covers keyboard focus, and :active covers the press itself.
Plain :focus fires on every focus, including mouse clicks. According to the Chromium blog (2020), :focus-visible runs the same heuristic the browser uses to decide whether to draw its default focus ring, so keyboard users get the style and mouse users don’t get a ring after every click.
W3C’s WCAG 2.2 Technique C45 recommends exactly this selector for keyboard focus indication, and ties it to success criterion 2.4.7, Focus Visible.
.btn:hover,
.btn:focus-visible {
background-color: #1e40af;
}
.btn:active {
transform: translateY(0);
}
Order matters here. :hover and :active have equal specificity, so :active goes last or the pressed style never shows.
Disabled buttons
A disabled button still matches :hover. Scope the effect with .btn:not(:disabled):hover, or the dead button lifts and glows like a live one.
Cursor
Buttons keep the default arrow cursor unless you set cursor: pointer. Many teams add it to signal clickability, but it’s a design choice, not a requirement.
Safe properties to animate on hover
web.dev’s guidance on compositor-only properties names transform and opacity as the two properties the compositor can animate without triggering layout or paint.
| Property | Pipeline cost | Typical hover use |
|---|
| transform | Composite only | Lift, scale, fill slide |
| opacity | Composite only | Fade a pseudo-element overlay |
| background-color, color, border-color | Paint | Color shift |
| box-shadow | Paint | Depth, glow |
| width, height, padding, margin | Layout and paint | Avoid on hover |
Paint-level properties are fine on a single button. Layout properties are where the trouble starts, since they move neighboring elements and can shift the whole page when someone hovers.
Box-shadow is the usual paint-cost driver, because large blur radii tend to take longer to paint. Keep the radius modest, or draw the big shadow once on a pseudo-element and fade its opacity. A box shadow generator helps you settle the values before they reach the stylesheet.
Stopping layout shift on hover
- Keep border width constant and change only
border-color. - If the hover state adds a border, start with a 2px transparent one.
- For a thicker edge, use
box-shadow: inset 0 0 0 2px or outline. - To grow a button, use
transform: scale() and leave width and height alone.
Does will-change help?
The sources disagree. web.dev’s guide recommends promoting animated elements with will-change, while MDN calls it a last resort for performance problems that already exist, and warns that values like opacity create a stacking context up front.
For one hovered button, skip it. Add it only if you can see jank.
To check, open the Rendering panel in Chrome DevTools, turn on Paint flashing, and hover the button. A green flash marks every repainted region.
Hover effect techniques for buttons
Most hover effects on buttons are a variation on one of the techniques below.
Color shift
Change background-color, color or border-color and leave everything else alone.
It’s the cheapest effect, the most readable, and the easiest to keep accessible. It stops working when the hover color sits too close to the resting color, because the change disappears for anyone with low vision.
Lift with translateY and box-shadow
A lift pairs transform: translateY(-2px) with a deeper shadow. The transform is cheap and the shadow repaints.
Two things break it: a parent with overflow: hidden that clips the shadow, and a button sitting flush against its neighbor.
The shadow cost has a workaround. Put the larger shadow on a pseudo-element and transition its opacity.
Scale
A transform: scale(1.05) grows the button without moving anything else in the layout.
That also means it can overlap the elements beside it.
- Keep the factor small, around 1.03 to 1.08.
- Text can look soft mid-transition in some browsers.
Glow
A glow is a zero-offset box-shadow in the button’s own accent color. It reads well on dark backgrounds and is nearly invisible on white, where a shadow just looks like dirt.
It’s a paint-heavy effect, so keep it for one prominent button per view.
Gradient position shift
Gradients cannot be transitioned directly, so make the gradient twice as wide as the button and slide background-position instead.
.btn {
background-image: linear-gradient(90deg, #1d4ed8, #7c3aed);
background-size: 200% 100%;
background-position: 0 0;
transition: background-position 400ms ease-out;
}
.btn:hover {
background-position: 100% 0;
}
Picking the stops is the slow part, and a gradient generator shortens it. Registered custom properties can animate the stops themselves, but the position trick works in every browser.
Fill slide with ::before
A pseudo-element holds the hover color and scales in from one edge, so the fill moves on transform and never touches layout.
.btn {
position: relative;
overflow: hidden;
z-index: 0;
}
.btn::before {
content: "";
position: absolute;
inset: 0;
z-index: -1;
background: #1e40af;
transform: scaleX(0);
transform-origin: left;
transition: transform 300ms ease-out;
}
.btn:hover::before {
transform: scaleX(1);
}
The button needs position: relative and overflow: hidden for this to work. Set transform-origin to choose the direction, and give the text color its own transition, timed to match.
Border draw
The simple version transitions outline-offset or an inset box-shadow. A true drawing effect, where the line traces the button, needs pseudo-elements or SVG, and the patterns in border animation examples show how.
It usually goes one of two ways: an outline that grows outward on hover, or four gradient lines whose background-size animates in sequence.
The traced version is the heaviest effect here. Skip it on touch-first layouts.
Clip-path reveal
Transition clip-path on a pseudo-element from inset(0 100% 0 0) to inset(0) and the fill wipes in with a hard edge.
The shape function must match at both ends, with the same type and point count, or the browser cannot interpolate and the change snaps. It usually repaints on every frame, so a plain fill slide on transform is cheaper when you don’t need the shaped edge.
Choosing a hover effect by button type
Pick the simplest effect that makes the button look clickable. For most primary buttons that means a color shift, with a small lift only if the rest of the interface already uses elevation.
| Technique | Best fit | Strength | Main risk |
|---|
| Color shift | Primary, secondary | Cheap, clear | Low contrast between states |
| Lift | Cards with CTAs | Tactile feedback | Clipped shadow, crowding |
| Fill slide | Ghost, outline | Visible direction | Label contrast mid-animation |
| Gradient shift | Hero buttons | Brand character | Extra paint, off-brand fast |
| Glow | Dark UIs | Draws the eye | Invisible on light backgrounds |
A call-to-action button carries the one task the page wants done, so the hover should confirm it quickly and stay out of the way. A plain color shift does that.
On a primary button I’d stay with the color shift and maybe add a 2px lift. A secondary button should get a lighter shift than the primary. Ghost buttons already start as an outline, so a fill slide or a border color change suits them. Icon-only buttons have no label to act on, which rules out text-based effects, and a background tint or a scale works better there.
The fill slide is the effect I would steer people away from on a primary button. The label has to pass contrast against both the resting and the filled background, and halfway through the wipe it often passes against neither.
For more button styles to pair with these effects, a set of cool CSS buttons gives you starting points to adapt.
Why hover effects stick on touch screens
Touch screens have no true hover, so browsers emulate it on tap, and the emulated state stays on the element until the user taps somewhere else.
The Tailwind Labs pull request that added a fix for this describes it the same way, with a tapped hover style persisting on mobile until the next tap elsewhere.
Guarding hover styles with a media query
Wrap the hover rule in a hover-capability media query, and leave the keyboard rules outside it.
.btn:focus-visible {
background-color: #1e40af;
}
@media (hover: hover) and (pointer: fine) {
.btn:hover {
background-color: #1e40af;
transform: translateY(-2px);
}
}
Which query to use depends on what you want hybrid devices (touch laptops, tablets with a mouse) to do.
| Query | True when | Catch |
|---|
| (hover: hover) | Primary input can hover | Some browsers report a hovering primary input on touch screens |
| (hover: hover) and (pointer: fine) | Primary input hovers and is precise | Excludes hybrids where the mouse is secondary |
| (any-hover: hover) | Any attached input can hover | Also matches while the user is tapping |
Sources disagree on how reliable the plain hover query is. Michelle Barker’s write-up notes that on some Android versions a long press emulates hover, so the query evaluates true, which is why she adds pointer: fine.
Some developers in CSS Working Group discussions go further and say browsers can report a mouse-like primary input even on touch screens. And a WebKit bug report filed against iOS 13.4 documents the reverse failure, where a connected mouse did not match hover or pointer: fine at all.
MDN lists any-hover as widely available, supported across browsers since December 2018. The query has been usable for years, and the edge cases come from what devices report.
Whatever you choose, nothing a user needs should exist only in the hover state. The query removes the effect on touch, so the tap has to work without it.
Tailwind CSS hover variant behavior
Tailwind CSS added the opt-in hoverOnlyWhenSupported flag in v3.1, and its hover: variant only applies on hover-capable devices by default in v4.
Tailwind Labs flagged that as a breaking change, because some sites rely on hover styles firing on tap, such as menus that open on hover. A one-off exception is possible with an arbitrary variant.
If a Tailwind site has a hover-only menu, it breaks on upgrade. A hover effect on a button does not.
Accessibility requirements for hover effects
W3C’s WCAG 2.2 asks for 4.5:1 contrast on normal button text (success criterion 1.4.3) and 3:1 on the visual information that identifies a component and its states (1.4.11).
In practice the hover text needs 4.5:1 against the hover background, not only the resting one, while boundaries and the cues for states such as focus or selection need 3:1 against adjacent colors.
Inactive components are exempt from 1.4.11, which is why a grayed-out disabled button can fail it legally.
Run the hover colors through a color contrast check before they ship. A hover shade that darkens the fill can improve the text ratio and wreck the boundary ratio in the same step.
Passing the ratios doesn’t guarantee a visible hover. The criterion measures contrast against adjacent colors, not between a component’s own states, and W3C’s Understanding document for 1.4.11 says color changes between states don’t have to reach 3:1.
So a hover shade only slightly darker than the resting one can pass and still look like one flat area to some people. Add a second cue such as an underline or a border so the change doesn’t depend on color alone.
An accessible color palette generator is a quick way to find hover shades that pass against the button’s own background.
Reduced motion
MDN names scaling or panning large objects as triggers for people with vestibular disorders. A small button scale is a mild case, but dropping it costs nothing.
@media (prefers-reduced-motion: reduce) {
.btn {
transition-property: background-color, color;
}
.btn:hover {
transform: none;
}
}
The color fade stays and the motion goes.
WebKit’s post introducing the feature describes Apple.com using it to disable a scaling effect. To test your own, Chrome DevTools can emulate the setting from the Rendering tab.
Managing hover styles with custom properties, Tailwind CSS and Bootstrap
Store the hover color, duration and easing in custom properties, and every button on the site changes from one place.
:root {
--btn-bg: #1d4ed8;
--btn-bg-hover: #1e40af;
--btn-speed: 200ms;
--btn-ease: ease-out;
}
.btn {
background-color: var(--btn-bg);
transition: background-color var(--btn-speed) var(--btn-ease);
}
.btn:hover {
background-color: var(--btn-bg-hover);
}
The transition still runs because the computed background-color changes. A dark theme only redefines the variables, and the hover rules stay untouched.
Bootstrap’s own blog (2022) says v5.2.0-beta1 added CSS variables to all its components, buttons included.
The hover and active states have their own variables, --bs-btn-hover-bg, --bs-btn-hover-color, --bs-btn-hover-border-color and --bs-btn-active-bg. The custom button example in Bootstrap’s button docs shades the hover background by 10% and the active background by 20%.
.btn-brand {
--bs-btn-bg: #7c3aed;
--bs-btn-border-color: #7c3aed;
--bs-btn-hover-bg: #6d28d9;
--bs-btn-hover-border-color: #6d28d9;
--bs-btn-active-bg: #5b21b6;
}
Bootstrap’s .btn rule declares its own transition list. If you add a transform lift, extend that list in your override or the lift snaps.
Load your stylesheet after Bootstrap, or import Bootstrap into a cascade layer so unlayered rules win without raising specificity. A guide to overriding Bootstrap CSS covers the common routes.
Tailwind CSS handles all of this with utility classes.
transition-colors duration-200 ease-out sets up the transition.hover:, focus-visible: and active: cover the states.motion-safe: and motion-reduce: respond to the motion preference.group-hover: reaches child elements.
<button class="bg-blue-700 text-white transition-colors duration-200 ease-out hover:bg-blue-800 focus-visible:bg-blue-800 active:bg-blue-900">Save</button>
Conflicts between utilities are decided by their order in the generated stylesheet, not by their order in the class attribute. More Tailwind button patterns show how the variants combine.
Why a button hover effect is not working
Most dead hover effects come from a competing rule or a property that can’t animate, and now and then from something blocking the pointer. Force the state in DevTools first, because the Styles pane then shows which rule is winning.
- Right-click the button in the Elements panel and choose Force element state, or use the toggle in the Styles pane. Chrome for Developers lists
:hover, :focus, :active and :focus-visible among the states you can force. - Look for a crossed-out rule. If your hover declaration is struck through, another selector outranks it.
- Check for inline styles. A
style attribute, often written by a script or a page-builder plugin, beats any stylesheet rule. - Check the property itself. By default,
display does not transition, and neither does a change to or from height: auto. Newer opt-ins (transition-behavior: allow-discrete and interpolate-size: allow-keywords) cover both, but only in browsers that support them. - Look for an overlay.
pointer-events: none on the button, or another element stacked on top, means the pointer never reaches it. - Rule out stale CSS with a hard reload or a cleared build cache. A rule added to a cached file will not appear.
- If the effect works on desktop and is missing on a phone, the touch guard from earlier is doing its job.
Specificity is the most common culprit in step two. An ID-based rule such as #cta .btn outranks .btn:hover, and the hover never shows.
Lower the competing selector instead of raising yours. A CSS specificity calculator scores both selectors, so you can see which one wins before reaching for !important.
CSS Button Hover Effects FAQ
Can JavaScript replace CSS for hover effects?
Only for effects CSS cannot express, such as a highlight that follows the cursor or a ripple that starts at the click point.
Color shifts, lifts, scales and fills run in pure CSS without a script, so reach for JavaScript last.
How do you change a button’s text or icon on hover?
Text content cannot be animated, so stack two elements, or set a pseudo-element’s content in the hover rule, and swap between them.
Fade or slide the swap with opacity and transform, and reserve the button’s width so the label change does not shift the layout.
Do hover effects work on links styled as buttons?
Yes. :hover applies to any element, so the same rules work on an anchor that carries the button class.
Use a real button element for actions and a link for navigation, since the two behave differently with keyboards and assistive technology.
Why does a button flicker when it lifts on hover?
The lift moves the button out from under the pointer near its bottom edge, so the hover state drops, the button falls back, and the cycle repeats.
Put the :hover rule on a stationary wrapper and apply the transform to the child, or move the lift to a pseudo-element.
How do you delay a hover effect?
Add transition-delay to the :hover rule. The destination state’s rule decides the timing, so only the entry is delayed.
The exit still follows the delay on the base rule, which is none unless you set one.
What to Test Before Shipping CSS Button Hover Effects
A hover style that passes with the mouse alone is unfinished. Test with the keyboard first, because a missing focus style is a conformance failure. Touch comes next, since a stuck hover is visible on every tap, and the reduced-motion override is the cheapest fix of the lot at one media block.
Each check removes something. The hover guard drops the effect on hybrid devices that report touch as the primary input, and the reduced-motion block drops the lift.
Accept both losses. A plainer button costs less than a broken one.
The same transform and shadow techniques carry over to card hover effects and the wider set of CSS hover effects, where the touch guard matters just as much.