23 CSS Flip Cards

Three CSS properties carry the entire effect. A scene wrapper holds perspective: 1200px to establish the 3D viewing depth. An inner card element uses transform-style: preserve-3d so its child front/back faces participate in that 3D space. Both faces use backface-visibility: hidden so only the front-facing one is visible at any moment. The back face is pre-rotated rotateY(180deg) at rest so it starts face-down. On :hover of the scene, the card receives transform: rotateY(180deg); the back's pre-rotation and the live hover rotation cancel, leaving the back face forward-facing. A cubic-bezier(.4, 0, .2, 1) easing on transition: transform .7s gives the flip a natural deceleration. Zero JavaScript required — demos #01, #02, #04, #05, #11, and #12 in this collection ship this exact recipe.

:hover fires inconsistently on touch screens — some mobile browsers emulate it on tap, others don't fire it at all, and once flipped the visitor can't easily flip back without tapping outside. The reliable fix is a click handler that toggles an .is-flipped class on the card. CSS targets the class instead of :hover: .card.is-flipped { transform: rotateY(180deg) }. The JavaScript is six lines — query the card, listen for click (which fires on both touch and mouse), call card.classList.toggle('is-flipped'). Tapping again flips it back. Demo #16 in this collection (Click-to-Flip JavaScript Toggle Card) ships the full pattern with aria-pressed for screen readers and button semantics for keyboard support. If your target audience is >40% mobile (most e-commerce sites are), use the click-to-flip pattern not the hover one.

rotateY(180deg) flips the card around the vertical axis — the right edge moves toward the viewer and the left edge moves away, like turning a playing card over in your hand. This is the standard, intuitive flip used in 16 of the 18 demos here. rotateX(180deg) flips around the horizontal axis — the top edge moves away and the bottom edge moves toward the viewer, like flipping a calendar page. The vertical-axis flip works best for landscape-oriented cards (product cards, business cards, photos); the horizontal flip works best for portrait or square cards where the visual rhythm of top-to-bottom motion feels more natural — and stands out from the conventional rotateY everyone else uses. Demo #15 in this collection (Vertical Axis Top-to-Bottom Flip Card) ships the rotateX recipe, and it's the easiest one-line swap from any rotateY demo: just rename the property.

The default flip card recipe relies on a fixed-height scene container — both faces are absolutely positioned to fill it, so the card height stays stable no matter which side is showing. The moment your front face has 4 lines of text and your back face has 12, you have a problem: a fixed height that fits the back leaves the front looking sparse, and one that fits the front clips the back. The CSS-only fix uses display: grid on the scene with grid-template-areas: 'face' so both faces stack in the same cell, then animates the scene's height via a JavaScript ResizeObserver that watches whichever face is currently visible. Demo #17 in this collection (Dynamic Height Auto-Resizing Flip Card) ships the full pattern — scene height transitions smoothly to match the visible face. This solves the #1 unanswered question on Stack Overflow about flip cards.

Yes, if you build them right. The hover-only flip pattern fails keyboard users — there's no way to trigger the flip without a mouse. The click-to-flip pattern (demo #16) uses a real <button> element with aria-pressed="false" / "true" so screen readers announce the toggle state. The trivia quiz demo (#07) and the language flashcard demo (#06) use the same pattern. Every demo in this collection wraps animations in @media (prefers-reduced-motion: reduce) so visitors with vestibular sensitivity (about 35% of adults have some motion preference) get an instant state change instead of a 700ms 3D rotation. WCAG 2.2 non-text contrast (3:1) is met on every visible state, and focus rings stay visible during the flip animation.

This is the #1 first-time-implementer bug. When you apply transform: rotateY(180deg) to the parent card, the back face inherits the rotation — which mirrors all its text and images horizontally (right-to-left). The fix is to pre-rotate the back face by rotateY(180deg) at rest. The two rotations cancel: the back starts mirrored relative to its parent, then when the parent rotates 180deg, the back's local rotation flips it back to normal-reading. The same trick applies to rotateX flips — pre-rotate the back by rotateX(180deg). Without this pre-rotation, every word on the back will read backwards. Every demo in this collection includes the pre-rotation, and the howItWorks notes on demo #01 explain the math in plain English.

Wrap multiple flip-card components in a CSS Grid container with grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)) — the grid adjusts column count automatically based on container width: 4 columns on desktop, 2 on tablet, 1 on mobile, no media queries needed. Each card keeps its own perspective and flip independently (perspective is per-element, not per-grid). Set gap: 24px for breathing room. Demo #18 in this collection (Responsive CSS Grid Flip Card Matrix) ships this exact pattern with 6 cards in a single matrix. The whole grid is one component — no wrapper math, no JavaScript breakpoints, no resize listeners. It just works at any viewport width from 320px to 4K.

Yes — backface-visibility: hidden is a visual property, not a content-hiding property. Both the front and back HTML content sit in the DOM at all times, fully crawlable by Googlebot and indexable. The browser only hides the back visually until the flip rotates it into view. Compare this with content hidden via display: none or loaded via JavaScript after page paint — those forms of hidden content do get downweighted by Google because they're not part of the rendered page. Flip-card hidden content is closer to a tab interface (role="tabpanel" hidden) which Google has confirmed is fine for ranking. The lighthouse SEO score on every demo page in this collection is 100/100; the per-demo URLs are individually indexable; and the ItemList JSON-LD points to those URLs so Google understands the collection structure.