I kept running into the same small annoyance. I'd need one animated icon, so I'd hand-roll it in Motion, and the result never quite matched the rest of my icon set. Stroke weight slightly off, optical size a bit different, timing eyeballed differently every time. One icon is fine. Ten icons and you've lost a day to something that should have taken five minutes.
So I built Iconimate.
What it is
A curated set of animated SVG icons that drop in as React components. Hover animations, state transitions, that kind of thing. You import the component and use it:
import { Bell } from 'iconimate'
<Bell size={24} />
That's the whole API surface for basic use. Motion runs underneath but you never write animation code.
Why the Phosphor 256 grid matters
This is the part I actually care about, and it's the reason the project exists.
Most animated icon sets are drawn on their own grid. That's fine in isolation, but the moment you put one next to your existing icons it looks almost right, which is worse than looking clearly different. Stroke weights don't match. Optical centers drift. Your eye catches it even if you can't name what's wrong.
Every Iconimate icon is drawn on the Phosphor 256 grid, the same one Phosphor Icons uses. So if you're already on Phosphor, these sit in the same interface without any adjustment. Same stroke weight, same optical alignment, same visual density.
As far as I've found, no other animated icon set does this.
What it isn't
It's a fixed curated collection, not a tool for animating arbitrary icons. You can't feed it your own SVG and get an animation out. That's a deliberate scope choice: getting an animation to feel right takes hand-tuning, and a generic animator would produce results that feel generic.
Stack
React, Motion for animation, Phosphor Icons for base geometry, Next.js for the site.
Where it's at
Live, open source, and I'm adding new icons weekly. The list is mostly driven by what people request.
Site: iconimate.app
GitHub: [https://github.com/smammar100/Iconimate]
The thing I'm still second-guessing is animation timing. A few feel a touch slow to me but I've stared at them too long to judge. If you scrub through some and any stand out as off, I'd like to hear it. Icon requests welcome too.
And if you end up using it, a star on GitHub helps a lot.
Top comments (23)
Cool. A search would be fine for mobile UX. I'm interested in SVgs
The search point is a fair hit β thank you. The gallery leans on
Cmd/Ctrl + K, which is no use at all on a phone. A visible search field for mobile is a real gap, and I'll fix it.On SVGs, two halves to the answer:
Static: the glyphs are Phosphor's, unchanged, so you can pull the plain SVGs from phosphoricons.com right now, same MIT license, and mine are pixel-identical at rest.
Animated: not currently. The motion is React plus
motion, written as spring-based variants rather than declarative keyframes. I could bake those springs down to CSS keyframes and ship framework-agnostic animated SVGs, the cost is interruptibility, since a real spring interrupted mid-hover resolves from its current velocity and a baked keyframe track can't. For a plain hover in and out, that's probably an acceptable trade.Not promising it yet, but it's the most interesting request I've had. What are you building with, a non-React framework, or plain HTML?
Just to clarify, Iβm framework-less, but my original point wasnβt really about the framework. π I meant the long scroll to find each SVG on the gallery. A visible search would make that much easier on mobile.
Yeah, will be adding in the next release: mobile-friendly search. Thanks for the suggestion as well
It can be useful for other devices too. It took me a while to find search.
Thanks for the feedback.
Just added the search on mobile. Thanks for the feedback . Please star the repo if you like it
Nice! I already starred the repo. I had told you.
Means a lot
I am saving this post. This may be useful for me. I'll start the repo.
Appreciate it! If you hit an icon that's missing when you get to it, drop me a note; I'd rather build the ones people actually need than guess.
The iconset is already pretty comprehensive! I'll notify if I think something's missing.
I'm updating weekly it with new icons as well
Thanks, will be added in the next release
For some reason the comment got deleted. Here are the icons again:
Done will let you know
This is a really useful idea. Hand-rolling the same icon animations over and over is one of those small things that ends up eating way more time than it should. I especially like the decision to stick to the Phosphor grid so the animated icons actually feel consistent with an existing icon set.
Thanks <3
This looks soooo cool!
Is there a way to install all of the icons directly? I know how to do it manually from the repo but I was wondering if you are thinking of adding a npm command to make it easier :)
Will be adding it; thanks for the suggestions. Can expect it in the upcoming suggestions. Writing it down on my roadmap
does this work well with framer motion or is it a custom wrapper? ngl hand-rolling those every time is a pain lol
Sorry for the slow reply! Good news, it is motion (motion.dev, i.e. Framer Motion after the rename), so if you're already using it, you're set. No custom wrapper around it.
Each icon is just plain
Variantsplus two small shared pieces: auseHoverhook that gates enter/leave/focus/blur through one source of truth, and a token module of named springs and durations. That second one is exactly the pain you're describing β you stop re-deriving timings per icon and just reach forSWEEPorARRIVE.Both get inlined into the file the registry drops in, so the only runtime dep is
motionand you can edit any curve you disagree with.If there's an icon you keep hand-rolling, tell me which and I'll add it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.