It doesn't throw an error. The conversion succeeds, the file downloads, the size looks fantastic.
You find out three weeks later, when someone posts in the team channel: "the animation in the docs isn't animating."
Why this one is worth writing up
The cost of this bug isn't the fix — the fix takes a minute. The cost is that you already used the wrong number as a conclusion: it went into a format comparison, into a spec doc, into a message to your team, onto production.
So the detection method goes first.
Two entry points, two very different reads
I was standardising the animated assets on our docs site. The tool was ImgIng (imging.ai), which splits image work across separate panels — one for single images, one for animation. I fed the same 79.8 KB demo GIF (720×405, 36 frames, 2.88s) into both:
| Entry point | What the UI reported | Output |
|---|---|---|
| Animation workshop | 36 frames · 2.88s total / keep GIF · 64 colours · 36 frames | 21.3 KB |
| Convert panel → WebP | detected icon/line art · defaulting to PNG-8 · 64 colours | 6.5 KB |
| Convert panel → AVIF | detected icon/line art · defaulting to PNG-8 · 64 colours | 1.5 KB |
The column that matters is the middle one, not the right one.
The animation workshop read out a frame count and a duration, because it has to split frames to do its job. The convert panel classified the input as icon/line art — a category that only exists for still images. Those bottom two rows went down the single-image path. The sizes are small because there was less content to encode.
This isn't a bug. The convert panel is for still images; animation has its own entry point. But if you only watch the output size, you walk away believing AVIF compressed an animation to 1.5 KB — and then you make decisions with that.
Three signals, cheapest first
Signal 1: does the UI tell you the frame count? Anything genuinely handling animation has to split frames, so it knows how many there are. No frame count on screen is a strong hint you're on the wrong path.
Signal 2: is the reduction outside the plausible range? Format changes on animation typically buy you somewhere between a bit and a few times smaller. Dropping below a tenth should make you suspicious — that looks a lot more like N frames becoming 1.
Signal 3: play the exported file. Crude and completely reliable. Trust no number; drag the file into a browser tab and see whether it moves.
Picking a format by where it has to play
Once you're actually on the animation path, the choice isn't about bytes. It's about where this file ends up playing:
| Format | The constraint that matters | Where it fits |
|---|---|---|
| GIF | 256 colours per frame, bulky | Anywhere that must "just work": email bodies, older clients, chat forwarding |
| Animated WebP | True colour, alpha, broadly supported in modern browsers | The default for web and mobile — the balance point for most cases |
| APNG | True colour and full alpha, slightly larger than WebP | High-fidelity stickers and short animations that need real transparency |
| Animated AVIF | Smallest, but older devices may not decode it; on the browser-side path there's no alpha and the loop is fixed to infinite | Controlled, modern playback targets |
(Positioning follows the vendor's published format table; the actual constraints are probed at runtime in the tool.)
The three things that actually block the migration
Size is one axis, and rarely the one that stalls you.
1. Email clients. Support is all over the place and always has been. Animated content in marketing email is still GIF territory, and probably will be for a while.
2. In-app browsers. WeChat, LinkedIn, Instagram — the embedded webview doesn't necessarily decode what the system browser does. This needs a real-device pass before launch, not a caniuse check.
3. CDN and cache strategy. New format means new URLs, cache re-warming, and a <picture> fallback to write. This part is routinely bigger than the conversion work itself, and it's the part that gets left out of estimates.
How I ended up choosing
Internal docs and admin UIs: animated WebP, no fallback. The browser population is known.
Public marketing site: WebP with a GIF fallback in <picture>. Storing a second copy costs less than handling the compatibility reports.
Anything users save and forward — say, an operating walkthrough in a help centre that people screenshot and send to support: plain GIF. The requirement that it opens in whatever software they have beats the byte count, every time.
Limits
The sizes above come from one flat-palette UI recording, deliberately chosen as easy-to-compress footage. On gradients or live action the relative ordering shifts — GIF barely compresses that material at all, while WebP and AVIF pull further ahead. So use these numbers for the detection story, not to predict your own savings.
One more constraint worth knowing before you pick animated AVIF on the browser-side path: no alpha, and the loop is fixed to infinite. If either matters to you, that decision is already made.
