Why I built CSSVG (converting SVG animations into clean CSS)
I started working on CSSVG because I kept running into the same issue with SVG animations.
Most tools either rely on JavaScript-heavy libraries or generate CSS that’s hard to read and maintain. That becomes a problem when you want lightweight, production-ready animations that fit cleanly into a frontend codebase.
In many cases, I didn’t need a full animation library. I just needed clean keyframes that I could control and integrate directly.
So I built CSSVG.
It converts SVG animations into pure CSS keyframes with no runtime dependencies. The goal is to generate output that’s readable, minimal, and easy to tweak.
It works well for simple transforms, opacity animations, and UI interactions. But it struggles with complex timelines, filter-heavy effects, and advanced SVG-specific behavior where CSS doesn’t map cleanly.
I’m still refining things like:
Reducing unnecessary keyframes
Improving transform accuracy
Handling edge cases in overlapping animations
Live demo: https://cssvg.com
Curious how others approach SVG animations in production. Do you rely on libraries, or try to keep things in CSS where possible?
Interesting problem to solve , I've always reached for libraries out of habit, but never really questioned the overhead cost. What's the file size difference typically between your CSS output vs something like GSAP for a simple animation?
Good question. For simple animations, the CSS output is usually very small, often just around 1 KB or less, since it’s only keyframes and styles.
With something like GSAP, you’re also shipping the library runtime, which is much larger in comparison.
That said, it’s not really a direct comparison.
GSAP is great when you need timelines, advanced control, or complex animations.
CSSVG is more for cases where the animation is simple and already known, like transforms, opacity, or UI interactions, where pure CSS keeps the bundle lighter and easier to maintain.