30 CSS Hover Effects

Because transform and opacity are the only two CSS properties that animate on the GPU compositor thread — they don't trigger layout (reflow) or paint (repaint) on every frame. Animating width, height, top, left, margin, padding, border-width, or font-size forces the browser to recalculate the layout of every affected element AND every descendant, on EVERY frame of the animation — that's 60 layouts per second on a 60Hz display, 120 on a 120Hz one. At 4-16ms of layout cost per frame, the main thread saturates fast and the animation drops to ~30fps. This shows up directly in your INP (Interaction to Next Paint) Core Web Vital score — the metric that replaced FID in March 2024. The 30 demos in this collection all animate transform/opacity exclusively; even color-shift hovers use opacity on a sibling overlay instead of animating background-color (which is paint-only but still has cost). Tools like Lighthouse, WebPageTest, SpeedCurve, Calibre, and Chrome's DevTools Performance panel will flag layout-triggering animations as "Recalculate Style" or "Layout" entries — that's the smoking gun. Replace those properties with their transform equivalents (scale, translate, rotate) and the entries disappear from the flame chart.

No, but you should handle the mobile case deliberately. Three patterns: (1) Make the hover effect ALSO trigger on focus. .btn:hover, .btn:focus { ... } means keyboard users (Tab) and screen-reader users get the same visual cue desktop pointer users do. WCAG 2.4.7 requires this anyway. (2) For touch-only devices, use the @media (hover: none) media query to either suppress hover styles entirely or replace them with tap-active styles. The pattern: @media (hover: hover) { .btn:hover { ... } } — hover styles only apply on devices that have a real hover. (3) For touch-active feedback, use :active (fires on touchstart) with a slightly shorter transition than your hover version. iOS double-tap-zoom default kicks in on links — set touch-action: manipulation to disable. The 30 demos in this collection use the @media (hover: hover) and (pointer: fine) pattern so touch devices see only the static appearance, not the broken "sticky hover" state that older patterns leave on tap. Related: iOS Safari, Android Chrome, and Samsung Internet all support @media (hover: hover) since 2017.

Respect prefers-reduced-motion: reduce. Roughly 35% of adults experience some level of motion sensitivity (vestibular disorders, migraine, simple preference), and they set this OS-level preference (macOS Accessibility → Display → Reduce motion, Windows Settings → Accessibility → Visual effects → Animation, iOS Accessibility → Motion, Android Accessibility → Remove animations). Every demo in this collection wraps its continuous-animation rules in @media (prefers-reduced-motion: reduce) { .hv-NN__... { transition: none; animation: none; } } so users get the static end-state instead of a fade/slide/scale. Three failure patterns most online tutorials skip: (a) animation rules need explicit animation: none; setting transition: none alone doesn't stop keyframe loops. (b) For effects that DEFINE the interaction (e.g., the underline-draw IS the hover) — replace the motion with an instant state change, not nothing. (c) Test in real OS settings, not just DevTools emulation — older Safari versions had reduced-motion-detection bugs. WCAG 2.3.3 (Animation from Interactions) explicitly recommends this; the EU EAA and US Section 508 audits flag missing reduced-motion guards.

Demo 13 (3D Tilt Card), Demo 07 (Magnetic Liquid Button), Demo 29 (Dot Trail Cursor), and Demo 30 (Magnetic Pull) all use vanilla pointer-tracking JavaScript — no framework, no library. Total cost: ~30-60 lines per effect. The mechanic: listen for pointermove on the element, calculate the cursor position relative to the element's bounding box, and translate that into a CSS custom property the element's transform reads. For 3D tilt: --tx and --ty drive rotateY(var(--tx)) rotateX(var(--ty)). For magnetic: --mx and --my drive translate(var(--mx), var(--my)). Library competitor cost comparison: vanilla-tilt.js ships ~6kb gzipped for what's effectively 40 lines of pointermove logic. react-tilt wraps that in React for ~8kb. tilt.js jQuery plugin is ~10kb. GSAP can do magnetic pulls but the runtime is ~20-30kb depending on which plugins you import. Framer Motion + useMotionValue + useTransform achieves the same effect in React with ~40-50kb of runtime. The 6 JS demos here use requestAnimationFrame throttling so the pointermove handler runs at the screen refresh rate, not the (much higher) raw pointer event rate — important for low-end Android. They also use {passive: true} on the pointermove listener so scroll performance isn't blocked.

Tailwind's hover: variant + utilities cover the SIMPLE cases brilliantly: hover:bg-blue-600 hover:scale-105 hover:shadow-lg works for 80% of buttons. Where it breaks down: (a) Multi-element coordinated hover — animating an underline pseudo while the link's color shifts requires the underline to be a child or pseudo, and Tailwind utilities can't target ::before directly without arbitrary-variant syntax (verbose). (b) Pointer-tracking effects — Tailwind has no way to read pointer coordinates; you need JS regardless. (c) Keyframe-based effects (shimmer, neon pulse, ripple expand) — Tailwind 3.4+ added animate-[...] arbitrary values but defining @keyframes still requires CSS. (d) Multi-state choreography — when hover staggers multiple children with delays (Demo 05 Split Text), transition-delay via transition-delay-[100ms] works but the per-child stagger needs nth-child selectors that Tailwind doesn't expose as utilities. For these cases, drop into a @layer components rule with the custom selector / keyframe / nth-child math, then call it with @apply for the parts Tailwind CAN handle. The 30 demos here are written as raw CSS so they drop into any setup (Tailwind, vanilla, CSS Modules, styled-components, emotion, Vue scoped, Astro <style>) — copy the entire .hv-NN block into your stylesheet.

Those are JavaScript animation libraries that DRIVE the animation via JS each frame. This collection is pure CSS hover effects — the browser drives the animation natively. When to use this collection: static or progressively-enhanced sites, marketing pages, e-commerce product cards, blog post hovers, navigation, anywhere bundle size matters. Zero JS bytes for the 24 pure-CSS demos. When to use Framer Motion (~50kb React-only): orchestrated multi-element animations with shared state, gesture-driven UI (drag-to-dismiss, swipe gestures), animations that change based on React state. When to use GSAP (~25-50kb): complex timeline-based animations with pause/seek/reverse control, SVG morphing, audio-synced motion, professional animation tools. When to use AutoAnimate (~3kb): you just want list-add/remove animations without thinking. When to use react-spring (~25kb): physics-based natural-feeling React animations. For hover effects specifically: CSS wins on every dimension — bundle size (0 vs 25-50kb), runtime cost (GPU compositor vs JS each frame), accessibility (CSS respects prefers-reduced-motion automatically; JS libs require manual opt-in), and progressive enhancement (works without JS enabled). Reach for the JS animation libraries when you need timeline control, complex orchestration, or gesture handling — none of which apply to simple hover.

Hover transitions don't directly hurt Core Web Vitals — they're triggered by user interaction, so they don't affect LCP (Largest Contentful Paint) or CLS (Cumulative Layout Shift) which measure load-time experience. They CAN hurt INP (Interaction to Next Paint) if poorly written — INP measures the responsiveness of every user interaction including hover. Three failure patterns specifically tank INP: (a) Animating layout-triggering properties (width, height, top, left, margin, font-size, border) — every hover triggers a reflow. (b) will-change: transform applied to dozens of elements at once — promotes them all to GPU layers, exhausting GPU memory, causing per-frame composite cost to balloon. Use will-change only on elements about to be animated; remove it once the animation completes. (c) Massive box-shadow on hover (e.g., box-shadow: 0 0 100px rgba(0,0,0,0.3)) — repaints the entire shadow area on every frame. Solution: use filter: drop-shadow() which is GPU-accelerated, OR pre-render the shadow as a pseudo-element with opacity transition. The 30 demos in this collection: 95+ Performance score on Pixel 5 baseline in Lighthouse mobile profile, all use transform/opacity only, all use will-change sparingly (only on the specific element being animated). Audit your own implementation with Chrome DevTools Performance panel, Lighthouse, or WebPageTest — look for "Layout" or "Recalculate Style" entries during hover.

Quick decision guide for all 30 demos. For navigation links (top nav, footer links, in-text links): Demo 01 (Underline Draw) — the canonical accent without dominating attention. Demo 25 (Underline Slide Nav) for an animated indicator that moves between active items. Demo 27 (Strikethrough Link) for completed-state semantic links. For CTAs and primary buttons: Demo 09 (Shimmer Shine) for high-conversion CTAs that need to draw the eye. Demo 11 (3D Press) for tactile feedback signaling "clickable." Demo 12 (Ripple) for Material Design conformance. For secondary buttons: Demo 08 (Border Draw) for outlined buttons that animate the stroke. Demo 10 (Fill Wipe) for ghost-to-filled transitions. For product cards (e-commerce): Demo 13 (3D Tilt) for premium SaaS / iOS-native product pages. Demo 16 (Spotlight) for dark-theme dashboards where light follows cursor. Demo 17 (Slide Reveal) for content cards that reveal description on hover. For portfolio / showcase: Demo 14 (Card Flip) for before/after reveals. Demo 18 (Stack Lift) for image grids. For image galleries: Demo 19 (Zoom Pan) for product photos. Demo 22 (Duotone) for editorial brands. Demo 23 (Curtain Reveal) for dramatic before/after. Demo 24 (Ken Burns) for hero images. For premium / branded brand experiences: Demo 15 (Glassmorphism Card) for frosted-glass aesthetics. Demo 06 (Neon Glow Text) for cyberpunk / gaming brands. Demo 07 (Magnetic Liquid Button) for design-forward marketing pages. For headlines / hero text: Demo 04 (Gradient Text Reveal). Demo 05 (Split Text) for choreographed letter staggers. Demo 02 (Glitch) for gaming / Web3 brands. For interactive whole-page experiences: Demo 29 (Dot Trail Cursor) + Demo 30 (Magnetic Pull) for art-direction sites. All 30 demos: 100% Pure CSS or pure CSS + minimal JS, prefers-reduced-motion respected, INP-safe, MIT-licensed.