Animated WebP:
The Modern GIF Replacement.

In the hero video post I called animated WebP the surprise option, mentioned it in two paragraphs, and moved on. It deserves more than two paragraphs. Every time I see a website ship a multi-megabyte GIF in 2026, a little part of me dies, because the fix is a one-line command and the result is usually 80-90% smaller.

So here's the full picture: what animated WebP is, how it stacks up against GIF and video, how to actually create one, and the places it'll bite you.

An animated WebP example

WebP is mostly known as a still-image format, but the container supports animation: multiple frames, per-frame durations, looping, the works. If the image below is animating, you're looking at one right now.

That's Google's classic animated WebP test image, and it makes the point better than any benchmark: a full-color looping animation, rainbow and all, in a 37 KB file. The equivalent GIF of that clip is roughly ten times the size.

Animated WebP vs GIF

GIF is a format from 1989 that refuses to die, and almost everything about it is worse:

• File size: WebP supports lossy compression based on the VP8 video codec; GIF only has lossless LZW from the disco era. Converting a typical GIF to lossy WebP cuts it by 60-90%. A 4 MB GIF becoming a 400 KB WebP is a normal, boring result.

• Color: GIF caps out at 256 colors per frame, which is why GIF gradients look like topographic maps. WebP is full 24-bit color.

• Transparency: this one's underrated. GIF transparency is 1-bit: a pixel is either fully opaque or fully invisible, no in-between. That's why every transparent GIF has that crunchy white halo around the edges. WebP has a real 8-bit alpha channel on every frame, so an animated element can sit on top of any background with smooth anti-aliased edges, soft shadows, even semi-transparent glows. An animated logo that floats over a photo hero, an animated sticker on a colored card: GIF simply cannot do these cleanly, and animated WebP can.

The only thing GIF still wins on is nostalgia and the fact that you can paste one into basically anything, including apps that predate the iPhone.

Animated WebP vs video (WebM / MP4)

For photographic content longer than a few seconds, a real video file still crushes animated WebP on size. The video codecs get to use inter-frame tricks at bitrates WebP's encoder was never tuned for, and browsers stream video in chunks while a WebP has to fully download before it loops.

But video comes with baggage: autoplay policies, the muted/playsinline attribute dance, no video support at all in some contexts (Markdown renderers, README files, most email clients, CMS rich-text fields). An animated WebP is just an img tag. It goes anywhere an image goes, autoplays without asking permission, respects nothing and nobody. For a 2-second UI micro-interaction, that simplicity wins.

My rule of thumb: under ~5 seconds and needs to behave like an image, animated WebP. Longer, photographic, or needs sound or controls, video.

Browser support

This used to be the objection, and it's dead. Chrome has supported animated WebP since 2014, Firefox since version 65 (2019), and Safari since Safari 14 (2020, macOS Big Sur / iOS 14). Every current browser plays them, covering about 97% of global traffic. Unless your analytics show a meaningful audience on iOS 13 or Internet Explorer, you can ship animated WebP without a fallback.

If you do need one, the picture element handles it the usual way:

<picture>
  <source srcset="animation.webp" type="image/webp">
  <img src="animation.gif" alt="The same animation as a GIF">
</picture>

How to convert a GIF to animated WebP

Google's libwebp package (brew install webp) ships a dedicated tool, gif2webp:

gif2webp -lossy -q 75 input.gif -o output.webp

The flag that matters is -lossy. By default gif2webp converts losslessly, which preserves the GIF pixel-for-pixel but only saves maybe 20-30%. Lossy mode is where the 80-90% reductions come from, and at -q 75 you will not spot the difference on a GIF-quality source.

How to convert an MP4 (or any video) to animated WebP

For video sources, ffmpeg does it in one line:

ffmpeg -i input.mp4 -vf "fps=15,scale=720:-1" -loop 0 -q:v 70 -an output.webp

The two dials worth turning are fps and scale. Dropping from 30 to 15 fps halves the frames and most short loops genuinely don't need more; 720 pixels wide is plenty for an inline animation. The -loop 0 means loop forever, and -an strips audio, which WebP couldn't carry anyway.

If you're building the animation from rendered frames (say, out of After Effects), img2webp from the same libwebp package assembles a PNG sequence directly, alpha channel included:

img2webp -loop 0 -lossy -q 80 -d 66 frames/*.png -o output.webp

The -d 66 is the per-frame duration in milliseconds, so 66 ms is roughly 15 fps. This is the path I use for transparent animations: render the PNG sequence with alpha, assemble with img2webp, and you get a looping animated element with clean soft edges that drops onto any background.

The gotchas

• Image pipelines will eat your animation. Most server-side image processors (Glide in Statamic's case, and most CDN image transforms) decode only the first frame when they resize or convert. Run an animated WebP through your thumbnail pipeline and you get a still image out. Serve the original file directly and skip the transform step for these.

• No streaming. The whole file downloads before it plays smoothly, so the file-size discipline from the hero video post applies double here. If your animated WebP is pushing past 1-2 MB, it probably wants to be an MP4.

• Decode cost. Video gets hardware decoding; animated WebP is decoded on the CPU. One or two on screen is nothing. A grid of twenty autoplaying animations will make a mid-range phone warm.

• Tooling is thinner than GIF. Photoshop still won't export an animated WebP, and plenty of desktop apps show only the first frame. The command-line tools above are the reliable path, and sharp or ImageMagick cover the programmatic cases.

What about animated AVIF?

AVIF also supports animation and compresses even harder, but encode times are much longer, tooling is rougher, and the size win over a well-encoded lossy WebP is modest for short loops. Animated WebP is the sweet spot of compatibility, tooling, and effort today. Revisit AVIF when your pipeline already produces it for stills.

The takeaway

If you have GIFs on your site, converting them to animated WebP is the cheapest performance win available: one command per file, no markup changes beyond the file extension, and the vast majority of the bytes gone. And if you've been reaching for video just to get a small transparent animation on the page, stop fighting autoplay policies. An animated WebP with an alpha channel is an img tag that just works.