CSS Animation Generator

CSS transitions animate between two states (usually triggered by :hover or class changes) and require a trigger event. CSS animations use @keyframes to define multi-step sequences that can run automatically on load, loop infinitely, and define complex motion paths. Use transitions for simple hover/state changes; use animations for entrance effects, loading spinners, and continuous motion.

ease (default): slow start, fast middle, slow end — good for most UI animations. linear: constant speed — good for spinners and continuous motion. ease-in: slow start, fast end — good for exit animations (elements leaving the screen). ease-out: fast start, slow end — good for entrance animations (elements entering the screen). ease-in-out: slow start and end — good for back-and-forth or looping animations.

fill-mode controls what styles apply before and after the animation runs. "none" (default): element returns to its original styles after the animation ends. "forwards": element retains the final keyframe styles after completion. "backwards": element applies the first keyframe styles during the delay period before the animation starts. "both": combines forwards and backwards behavior. Most entrance animations should use "forwards" to keep the final state.

Set iteration-count to "infinite" and ensure your first and last keyframes have identical property values. For example, rotate: 0% { transform: rotate(0deg) } to 100% { transform: rotate(360deg) } loops smoothly because 360deg = 0deg. For bounce effects, use "alternate" direction so the animation reverses each cycle. Avoid abrupt property jumps between 100% and 0% keyframes.

Yes. CSS supports multiple animations on a single element by comma-separating animation values: animation: fadeIn 0.5s ease forwards, slideUp 0.5s ease-out forwards. Each animation can have independent timing, delay, and keyframes. Be careful with conflicting properties — if two animations modify the same property (e.g., transform), the last one in the list wins.

Animations on transform and opacity properties are GPU-accelerated in all modern browsers and run on the compositor thread — they do not trigger layout or paint and are extremely performant. Animating layout-triggering properties like width, height, margin, or top causes layout recalculations (reflow) and should be avoided. Use transform: translateX() instead of left, and transform: scale() instead of width for smooth 60fps animations.

Wrap non-essential animations in the prefers-reduced-motion media query, which exposes an OS-level accessibility setting users enable when motion causes discomfort (vestibular disorders, migraines, nausea). The pattern: define your animations normally, then add @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; animation-iteration-count: 1 !important; transition-duration: 0.01ms !important; } } to neutralize them — or, more surgically, only opt IN to motion inside @media (prefers-reduced-motion: no-preference). Essential motion (a loading spinner that conveys progress) can stay, but parallax, large slides, auto-playing carousels, and bouncing entrances should be reduced or removed. Respecting this isn't optional polish — it's a WCAG 2.1 requirement (Success Criterion 2.3.3) and prevents real physical discomfort.

Use cubic-bezier(x1, y1, x2, y2), which defines the acceleration curve with two control points. The keyword easings are just named beziers — ease is cubic-bezier(0.25, 0.1, 0.25, 1), and you can craft your own for a specific feel: a gentle 'ease-out' for entrances might be cubic-bezier(0.16, 1, 0.3, 1), while values where y goes above 1 or below 0 create overshoot and anticipation (a slight 'past-the-target-and-back' bounce). The x values must stay between 0 and 1 (time can't run backward) but y can exceed that range for springy effects. For stepped animations (sprite sheets, typewriter effects) use steps(n) instead, which jumps in discrete increments rather than interpolating smoothly.