20 CSS Rotate Animations

Two declarations. Define the keyframes — @keyframes spin { to { transform: rotate(360deg) } } — then apply them with animation: spin 4s linear infinite. You do not need a from block, because the browser uses the element's current state as the implicit starting frame. The detail that matters more than people expect is linear. The default timing function is ease, which accelerates at the start and decelerates at the end; on a one-shot animation that reads as natural, but on an infinite loop the deceleration runs straight into the next cycle's acceleration and produces a visible stutter at every seam. Nothing about the code looks wrong, and the effect is subtle enough that people often blame the frame rate instead. Continuous rotation is linear; save the eased curves for finite, triggered rotations like a chevron flipping or a card fanning open.

Because transform-origin defaults to 50% 50% — the element's centre — and most real-world rotations do not pivot there. A gauge needle pivots at its base, so it needs transform-origin: 50% 100%. A hinged door or a book cover pivots at one edge: transform-origin: 0 50%. A hanging sign swings from the top: transform-origin: top center. This is the single most common source of "my rotation looks wrong" — the angle is correct and the pivot is not, so the element swings through an arc instead of turning in place. The origin accepts percentages, keywords and lengths, and it resolves against the element's border box, which is worth remembering when padding changes the box size. Set it explicitly whenever the pivot is not the centre, rather than relying on a default that is right only some of the time.

Because each transform function operates on the coordinate system the previous one left behind. transform: rotate(45deg) translateX(100px) rotates the element's axes first, then moves it 100px along the rotated X axis — so it travels diagonally. transform: translateX(100px) rotate(45deg) moves it 100px along the original horizontal axis, then spins it in place at the new location. Same two functions, same values, completely different outcomes. There is no way to write the shorthand order-independently. The modern alternative is the independent rotate, scale and translate properties, which apply in a fixed order (translate, then rotate, then scale) regardless of the order you declare them in — and, more usefully, can be animated separately without one overwriting the other, which the transform shorthand cannot do.

Use animation-play-state: paused. The important property of this approach is that it freezes the element at its current angle and resumes from exactly there — unlike removing the animation, which snaps the element back to its starting rotation and reads as a glitch. Apply it on :hover and on :focus-within together, because a keyboard user has no hover state and would otherwise have no way to stop the motion. This is not only polish: WCAG 2.2.2 requires a pause, stop or hide mechanism for any motion that starts automatically and runs longer than five seconds, which most decorative infinite rotations do. A visible toggle button is the most robust answer, since it works for every input method and does not depend on the pointer resting in a particular place.

Continuous rotation is one of the more reliable vestibular triggers, so it deserves a real fallback rather than a token one. Wrap the animation in @media (prefers-reduced-motion: no-preference) so motion is opt-in rather than opt-out, and give the reduced case a meaningful end state — the finished position, a static angle change, or a cross-fade. The mistake to avoid is degrading to nothing: if an element only communicates its state through spinning, removing the spin removes the information. A loading indicator that stops moving must still say it is loading. Keep the reduced variant visually complete rather than blank, and test it by toggling the setting in your OS rather than trusting the media query to be right by inspection.

Yes, provided you rotate with transform rather than faking it. transform and opacity are compositor-only properties, which means the browser can animate them on a separate thread without recalculating layout or repainting — that is what keeps a rotation at 60fps even while the main thread is busy. Animating width, height, top or left to approximate rotation forces layout on every frame and will visibly stutter. Two further notes. will-change: transform promotes an element to its own layer and can help a heavy animation, but it costs memory per element, so apply it to the few elements that need it rather than to everything that moves. And if you are animating a custom property that holds an angle, register it with @property and a syntax of angle — an unregistered custom property is a string to the engine and will jump between values instead of interpolating.

Use animation-timeline: view(), which binds an animation's progress to an element's position in the viewport with no JavaScript and no scroll listener. A scroll event handler runs on the main thread and fires far more often than the screen refreshes, which is a well-known way to damage Interaction to Next Paint; a scroll-driven animation runs on the compositor instead. The caveat is support: Chrome shipped it in 115 and Safari in 26, but Firefox has not shipped it at all. That makes an @supports (animation-timeline: view()) gate mandatory rather than optional, with the static, correctly-oriented state declared first — otherwise Firefox users see the element frozen at its starting angle, which usually looks broken rather than merely unanimated. animation-range is worth learning alongside it, since "the rotation happens too early" is almost always a range problem rather than a timeline one.

The CSS ports unchanged — every .rot-NN selector and custom property is framework-agnostic, and fifteen of the twenty demos need no JavaScript at all. Where a demo does use script, it only writes a custom property and lets the stylesheet render, so the framework layer stays thin: a useEffect that sets --rot-13-angle is the whole React integration, and the cleanup return is trivial because there is no animation loop to tear down. Tailwind ships rotate-* utilities for static angles and arbitrary values such as rotate-[17deg], but it has no first-class keyframe rotation, so the @keyframes block still lives in your stylesheet or an @layer. One trap that is framework-independent: if you toggle an animation by adding and removing a class, the element resets to its start angle each time. Toggle animation-play-state instead when you want it to resume where it stopped.