Why WAAPI is the right choice in 2026

Ten years ago, SVG animation was a choice between SMIL (deprecated by the W3C), CSS (limited to transforms), and JavaScript libraries (GSAP, Velocity.js). In 2026 there's a better answer: the Web Animations API (WAAPI), stably available in all mainstream browsers since 2020. It combines the declarative elegance of CSS with the power of JavaScript control — without an additional library.

A format overview for animations is in our web animation format-choice post; this post goes into the SVG depth.

The basic pattern

WAAPI animates any element property. For SVG that means: all attributes SVG natively supports — path data, stroke properties, transform matrices, gradients. The call:

const path = document.querySelector("svg path");
path.animate(
  [
    { strokeDashoffset: 1000 },
    { strokeDashoffset: 0 }
  ],
  {
    duration: 2000,
    easing: "cubic-bezier(0.4, 0, 0.2, 1)",
    fill: "forwards"
  }
);

Use case 1 — drawing effect (stroke animation)

The classic: an SVG path is traced step by step. Works via stroke-dasharray and stroke-dashoffset:

<svg viewBox="0 0 100 100">
  <path id="logo" d="M10,50 Q50,10 90,50 T10,50"
        fill="none" stroke="currentColor" stroke-width="2"
        stroke-dasharray="240" stroke-dashoffset="240"/>
</svg>

<script>
  document.getElementById("logo").animate(
    [{ strokeDashoffset: 240 }, { strokeDashoffset: 0 }],
    { duration: 1500, easing: "ease-out", fill: "forwards" }
  );
</script>

The stroke-dasharray value must be at least as large as the path length (determinable with path.getTotalLength()). More elegant than the old SMIL <animate> tag, more robust than CSS keyframes.

300 × 250 — Rectangle
Cookie-Banner ausstehend

Use case 2 — path morphing

Two SVG paths morph into each other. Path morphing needs compatible path structures (the same number of anchor points). Tools like Figma's smooth animation or the flubber library help with preparation.

const morph = path.animate(
  [
    { d: "path('M10,50 L90,50')" },
    { d: "path('M10,50 Q50,10 90,50')" }
  ],
  { duration: 800, easing: "ease-in-out" }
);

Important: path morphing via d animation only works reliably in Chrome, Firefox, and Safari since the 2024 versions. For older browsers: a fallback via SMIL or GSAP.

Use case 3 — stroke-color gradient animation

Stroke colors can be interpolated over time:

path.animate(
  [
    { stroke: "#d4a017" },
    { stroke: "#3b82f6" },
    { stroke: "#10b981" }
  ],
  { duration: 3000, iterations: Infinity, direction: "alternate" }
);

Browsers interpolate color values in sRGB (default) or in another color space if specified via animation-composition. Display-P3 interpolation is available since Safari 17.4 and Chrome 122.

Use case 4 — scroll-triggered animation

The scroll-driven animations API (Chrome 115+, Safari 18+, Firefox 130+) lets you bind SVG animations directly to scroll progress — without an IntersectionObserver setup:

path.animate(
  [{ strokeDashoffset: 240 }, { strokeDashoffset: 0 }],
  {
    duration: 1,
    timeline: new ScrollTimeline({
      source: document.scrollingElement
    })
  }
);

This lets hero SVG logos "draw themselves" as you scroll down — more elegant than any classic scroll-magic script.

300 × 250 — Rectangle
Cookie-Banner ausstehend

Performance implications

WAAPI runs on the compositor thread for supported properties (transform, opacity). Path animations via the d attribute or stroke-dashoffset, however, run on the main thread — which is fine for small SVGs but becomes problematic for complex paths (1,000+ anchor points).

Rules of thumb:

  • Up to 200 anchor points: use WAAPI directly.
  • 200–1,000 anchor points: only animate transform/opacity, minimize path changes.
  • 1,000+ anchor points: consider Lottie or Canvas rendering.

WAAPI vs. CSS animations

CSS animations are declarative and simple — but:

  • CSS can't animate SVG path d attributes (only transform, opacity, stroke properties).
  • CSS has no programmatic control over play/pause at runtime (a class-toggle workaround is needed).
  • WAAPI returns an Animation object with play(), pause(), reverse(), cancel(), finish().

WAAPI vs. GSAP

GSAP (GreenSock) is an 80 KB library that was the pro tool for web animations since 2010. For most SVG animations in 2026, GSAP is no longer necessary:

  • WAAPI: 0 KB, native, fast.
  • GSAP: 80 KB minified, best cross-browser consistency, best plug-ins (MorphSVGPlugin, MotionPath).

GSAP stays worthwhile for: highly complex animations with timeline choreography, pro path morphing (MorphSVGPlugin is still better than WAAPI here), legacy browser support (IE11 is dead, but some embedded browsers are old).

300 × 250 — Rectangle
Cookie-Banner ausstehend

WAAPI vs. Lottie

Lottie comes from After Effects — if a designer composed the animation in AE, a Lottie export is the simplest route. WAAPI, by contrast, requires hand-code. For small UI animations (logo reveals, icon transitions) WAAPI is much more lightweight. For complex choreography with dozens of layers, Lottie remains the right choice.

Accessibility

WCAG 2.2 requires respect for prefers-reduced-motion:

const prefersReduced = window.matchMedia(
  "(prefers-reduced-motion: reduce)"
).matches;

if (!prefersReduced) {
  path.animate(...);
}

With reduced motion: jump to the end state, no animation.

Recommendation matrix

  • UI icon transitions: WAAPI directly.
  • Logo drawing animation on scroll: WAAPI + ScrollTimeline.
  • Path morphing between two states: WAAPI with compatible paths.
  • Complex path-morphing sequences: GSAP MorphSVGPlugin.
  • After Effects composition with 30+ layers: Lottie.
  • Charts and data visualizations: WAAPI with D3.js paths.
300 × 250 — Rectangle
Cookie-Banner ausstehend

Sources

W3C — Web Animations Level 1 · MDN — Web Animations API · W3C — Scroll-driven Animations · flubber — SVG Path Interpolation · GSAP · web.dev — Scroll-driven Animations · Can I Use — Web Animations API.