Search DevTools

Jump to any tool or page

SVG Animation Playground

Paste an SVG, pick a preset, and tweak Motion transitions (tween, spring, inertia). Export as a ready-to-use React component.

SVG Source

198 chars

Animation

Transition

Preview

Paste an SVG to see the animated preview.

Icons courtesy of Lucide, free and open source.

Generated Code

React component (.tsx)

Paste an SVG to generate a ready-to-use component.

Visual Creation

About SVG Animator

Build and preview SVG animations, generating the CSS or SMIL markup needed to reproduce them. SVG's coordinate system is the source of most surprises: transform-origin resolves against the element's own bounding box in a user-unit space that has nothing to do with CSS pixels, so a rotation that looks centred in a design tool spins off-screen in the browser.

Frequently asked questions

Should I use SMIL, CSS, or JavaScript?
SMIL — the animate and animateTransform elements — is declarative and can do things CSS cannot, notably motion along an arbitrary path via animateMotion. It was marked deprecated by Chrome in 2015, that deprecation was reversed, and it remains unsupported in Internet Explorer and inconsistently supported in some embedding contexts. CSS animation is hardware-accelerated for transforms and opacity and is the safe default. Reach for JavaScript when you need interaction, scroll linkage, or physics that keyframes cannot express.
Why does transform-origin behave unexpectedly on SVG elements?
In HTML, transform-origin defaults to 50% 50% of the element's box. In SVG the default is 0 0 — the origin of the current user coordinate system, which for a nested group may be far from the shape. So a rotation swings the element around a distant point rather than its own centre. Setting transform-box: fill-box makes percentage origins resolve against the element's own bounding box, which is usually the behaviour you actually wanted, and it is well supported in modern browsers.
Why does the SVG transform attribute conflict with the CSS transform property?
They are separate mechanisms writing the same underlying matrix, and CSS wins. Set transform="translate(10,20)" in markup and then animate transform in CSS, and the attribute value is discarded the moment the CSS property applies — the element snaps to a new position at animation start. Keep static positioning in the parent group's attribute and animate the child in CSS, or move everything into CSS. Note also that CSS transforms on SVG require units on lengths, whereas the attribute takes bare user units.
How does stroke-dasharray produce a line-drawing effect?
Set stroke-dasharray to the path's total length, so the whole path is one dash followed by an equally long gap, then animate stroke-dashoffset from that length to zero, which slides the dash into view. Get the length from getTotalLength in JavaScript rather than guessing. Two caveats: the effect only works on stroked paths, not fills, and it is not obviously animatable in pure CSS without a hardcoded length — which breaks when the path or its scaling changes.
Which SVG animations are actually performant?
Transform and opacity can be composited on the GPU and stay smooth on complex artwork. Almost nothing else in SVG can — animating d, stroke-dasharray, width, or filter parameters forces a re-rasterisation of the shape every frame on the CPU, and a handful of concurrently morphing paths will drop frames on mid-range mobile. Filters such as blur are the most expensive of all. If a design demands animated geometry, reduce the number of animated nodes rather than hoping for GPU acceleration that is not available.