Pure CSS Hover Effects

How these hover effects work

Every effect in this collection starts from the same CSS building blocks. The :hover pseudo-class detects the interaction. As MDN defines it, :hover matches when the user interacts with an element with a pointing device, such as a mouse cursor. The state applies automatically while the pointer sits over the element, with no JavaScript listening for mouseenter or mouseleave events. The browser does the hit testing for you, and the same rule works for links, buttons and any other element you attach the class to.

The motion comes from the transition property. When a property listed in transition changes between the default state and the :hover state, the browser interpolates the intermediate values over the declared duration instead of switching instantly. The underline slide animates transform: scaleX() from 0 to 1 along its own easing curve while the lift and scale cards animate transform and box-shadow together, because each transition declaration can list several properties separated by commas. Rotate uses the cubic-bezier() timing function with a slight overshoot, and the sweep effects move a gradient layer with translateX(). These are all examples of interpolating between two computed values, which is the core mechanism behind every preview on this page. The easing function controls how fast the value changes across the duration, and that curve is what makes a lift feel springy rather than abrupt.

The pulse card is the exception. It runs a CSS animation driven by @keyframes, looping for 0.8s while hovered.

Edge cases and browser behavior

Touch devices have no hover state in the mouse sense. MDN notes that most touchscreen browsers only support :hover partially, some keeping the style stuck after a tap until another element is touched. A hover-only effect can feel random on a phone, so pair the :hover rule with :focus-visible for keyboard and switch users, and treat the animation as a desktop enhancement rather than the only feedback channel.

Motion sensitivity is a second boundary. WCAG 2.2 includes a success criterion for animation from interactions, expecting that non-essential movement can be turned off. The prefers-reduced-motion media query is the standard way to honor that preference: wrap the pulse loop or any strong displacement in a query that disables it. Color shifts also matter, since WCAG 2.2's contrast criteria apply to text and to meaningful graphical states.

Common mistakes and alternatives

The most frequent mistake is toggling a property that cannot interpolate. Display, for example, has no intermediate value, so the browser snaps between none and block with no transition at all. The second mistake is forgetting that :hover alone never fires for keyboard users, and the tab key then produces no feedback. The third issue is animating box-shadow on large surfaces, where repainting every frame is heavier than moving a transform. MDN's animation guide recommends favoring transform and opacity for smoother animation.

Alternatives abound. Replace translateY with scale for a press feel, or fade the label color instead of moving geometry. Short transitions, roughly 150 to 400ms, match the timing users expect.

FAQ

The hover state and transition references behind these snippets

The behavior these snippets rely on is defined by the CSS specifications below.

• MDN: the :hover pseudo-class defines when the hover state matches and how touch browsing behaves, which backs the state detection notes above.
• MDN: CSS transitions documents the property, duration and timing functions that drive the interpolated motion in these cards.
• MDN: box-shadow specifies the shadow syntax used by the lift, glow and pulse effects.
• MDN: Using CSS animations explains the @keyframes rules and the animation shorthand behind the pulse loop.
• WCAG 2.2 provides the contrast criteria and the animation-from-interactions requirement that apply to hover feedback and reduced-motion users.