Animated GIF vs WebP vs AVIF

We encoded the same three-second clip into all three formats. At the best quality a 256-colour GIF could reach for it, an animated WebP matched that quality at 4.6 times smaller, and an animated AVIF matched it at 87 times smaller. GIF's real limit isn't file size, though: it's the 256-colour palette and the all-or-nothing transparency both date to 1987.

Which animated format should you use?

Use GIF when:

• The destination is unpredictable: old chat clients, email, forums and CMSes that only recognise GIF as "the moving one."
• Universal playback matters more than file size, because nothing else animates in quite as many places.

Use WebP when:

• You control playback, on a website or in an app, and want the file two to five times smaller with a real alpha channel. Every major browser has decoded it since Safari added it in September 2020.

Use AVIF when:

• File size is the priority and your audience is on a browser from the last few years. It beat WebP by a wide margin in our test, though see the transparency section below before using it for anything with a soft edge.

FileFlip converts GIF to WebP and GIF to AVIF, and it's worth knowing before you click either: today, both keep the first frame only. More on that below.

GIF vs WebP vs AVIF at a glance

How much smaller are WebP and AVIF than an animated GIF at the same quality?

WebP came out 4.6 times smaller and AVIF about 87 times smaller, both matched to the exact quality our best-effort GIF reached.

We took a 3-second, 480-pixel-wide, 12fps clip (36 frames) and encoded it three ways: an animated GIF with a diff-based 256-colour palette and Sierra dithering, the best a GIF encoder does for this kind of content, then animated WebP and AVIF swept across their quality range. Full method at the bottom of the page.

That gap is this lopsided because GIF's own ceiling is low. An SSIM of 0.9010 is well short of the roughly 0.97 a good still-image JPG or WebP encode reaches, as our WebP vs JPG measurements show, so AVIF only has to be pushed down to a fairly aggressive setting to match it. Google's own testing across a large image set puts animated AVIF at a median 86% smaller than animated GIF, a gap almost as large as ours from a different method, comparing typical files rather than one clip matched to GIF's own ceiling.

Full quality sweep, so you can see where each format lands away from that matched point:

How does each format actually store the frames?

GIF writes each frame as its own LZW-compressed, indexed-colour image, with a Graphic Control Extension next to it that sets the delay and whether the next frame replaces the whole canvas or just draws over it. That per-frame independence, defined in the GIF89a spec, is part of why GIF compresses motion so poorly: it can skip redrawing unchanged pixels, but it can't predict a new frame from an old one the way a video codec can.

WebP's animated form adds ANIM and ANMF chunks around a sequence of lossy or lossless still frames, defined in RFC 9649. Each frame carries its own dispose and blend mode, closer to GIF's model than to a video codec's, which is why WebP's gain over GIF here comes mostly from full 24-bit colour and a better still-image codec rather than from predicting frames.

AVIF's animated form is an avis-branded HEIF file holding a sequence of AV1-coded samples, laid out in the AVIF specification. AV1 is a video codec first, so those samples can predict one frame from the motion in the last one. That's the mechanism behind the 87x gap above: AVIF isn't just compressing better frames, it's compressing the differences between them.

Do animated WebP and AVIF support real transparency, unlike GIF?

Yes. Both carry a full 8-bit alpha channel on every frame; GIF marks one palette colour "transparent" and every pixel using it is either fully shown or fully skipped, with nothing in between.

That gap matters more in motion than in a still image: a hard-edged cutout that a static logo hides in a corner instead crawls and re-aliases on every one of an animation's frames as the subject moves. See alpha channels and transparency for how few distinct alpha values actually survive a GIF save on a single still edge.

Does converting an animated GIF to WebP or AVIF on FileFlip keep the animation?

No, not today. FileFlip's image converter reads a single frame from whatever you give it, so an animated GIF converted to WebP or AVIF comes back as one still image: the first frame.

That isn't a caveat buried in fine print. FileFlip's own GIF to WebP converter page says it directly: "ImageMagick is asked for a single image, so only the first frame, page, or icon size is read." We confirmed it by running the conversion: a 20-frame test GIF came back a single-frame WebP, every time. The reason is that FileFlip's image engine calls ImageMagick's single-image read rather than its multi-frame collection read, and that applies to every image format on the site, not just GIF, WebP and AVIF.

If you need the animation preserved, this specific conversion isn't the tool for it, and we'd rather say so than have you find out after the download finishes. The GIF to WebP and GIF to AVIF converters are still useful for a different job: pulling a single poster frame out of an animated GIF without opening an editor.

Are animated WebP and AVIF supported everywhere in 2026?

WebP, yes, close to everywhere. AVIF, mostly, with one rough edge specific to animation.

Animated WebP has shipped in every major browser since Safari added WebP support in September 2020, per Google's WebP FAQ. Static AVIF arrived earlier than animated AVIF in more than one engine: MDN's image format guide notes Firefox supported still AVIF images from version 93 but didn't add animated AVIF until version 113. Safari's story is similar, with full animated AVIF support landing in Safari 16.4 in March 2023, after Safari 16.1 shipped stills-only support a few months earlier.

Even where it's supported, animated AVIF with transparency isn't fully settled. Browser engineers flagged transparency-performance bugs in animated AVIF across Chrome, Firefox and Safari in a web-platform-tests interop tracking issue opened in September 2025, serious enough that fixing it became an Interop 2026 focus area. If you're shipping an animated AVIF with a soft alpha edge rather than a solid background, test it in the browsers you actually care about before you commit to it.

Can FileFlip turn a video into an animated GIF?

No. Image and video stay in separate families on FileFlip: there's no route from an MP4 to a GIF, WebP or AVIF, and none back the other way either. If a page or a post tells you to "just convert your video to a GIF," that's a different kind of tool doing frame extraction and re-encoding, not a straight format conversion, and it isn't something FileFlip does.

Common questions

Is APNG the same thing as an animated PNG?

Yes, APNG is PNG's animated variant, and current versions of every major browser render it, per caniuse. FileFlip's PNG format doesn't carry animation, though: our registry lists PNG's animation support as unsupported, so a PNG conversion here always produces a single still frame, APNG source or not.

Why do some animated GIFs look so much worse than others at the same file size?

The palette and dithering choices the encoder made, not anything about the GIF format itself. Our test used a diff-based, per-frame-optimised palette with Sierra dithering, close to the best a GIF encoder can do; a naive, fixed-palette encode of the same clip would look noticeably worse at the same size, or noticeably bigger at the same quality.

Can Photoshop or Preview open an animated WebP or AVIF file?

Current versions, yes. Photoshop has read and written WebP natively since version 23.2 in 2022, and macOS Preview opens both formats on any supported macOS release. Older installs of either may only show the first frame or refuse the file outright.

Does the number of frames change which format wins?

Not the ranking, only the margin. More frames give AVIF's inter-frame prediction more redundancy to exploit against GIF's independent frames, so the size gap in our table would likely widen on a longer clip and narrow on a shorter one.

Convert between them

FileFlip converts GIF to WebP and GIF to AVIF inside your browser, on a WebAssembly build of ImageMagick. The file never leaves your machine, there's no account, and nothing is queued on a server, and as covered above, what comes back is a single still frame rather than a preserved animation.

See the GIF, WebP and AVIF format references for more on each container.

How we measured this

• Clip: 3 seconds of the Big Buck Bunny 1080p source (Blender Foundation, CC BY 3.0), starting 2 seconds in, scaled to 480px wide at 12fps: 36 frames.
• GIF encode: FFmpeg's palettegen/paletteuse filter pair, stats_mode=diff for a frame-aware 256-colour palette and dither=sierra2_4a, which is close to the best a GIF encoder does for this kind of content.
• WebP and AVIF encodes: FFmpeg's libwebp_anim and libaom-av1 encoders, swept across quality 15-90 and CRF 50-10.
• Quality metric: SSIM, matching the method our other image posts use. FFmpeg's own demuxer only reads the first frame back out of a multi-frame WebP or AVIF file (confirmed against FFmpeg 8.1.2), so every candidate and the reference clip were exploded to numbered PNG frames with ImageMagick and FFmpeg, coalescing each GIF frame first since GIF stores everything after the first frame as a diff. SSIM was measured frame by frame with FFmpeg's ssim filter and averaged across all 36 frames.
• Matched-quality comparison: we linearly interpolated each format's size-versus-SSIM sweep to the SSIM the GIF achieved, the same method WebP vs JPG uses for stills.
• Caveat: this is one clip of cartoon-rendered animation, not live-action footage or a screen recording, and the ratio moves with content and with how good the GIF encode is to begin with. Treat 4.6x and 87x as this clip's numbers, not a universal average.
• Tools: FFmpeg 8.1.2 with libaom and libwebp, ImageMagick 7.1.2-28, on macOS.

The script is in the repository at apps/nextjs/scripts/benchmark-animated-image.mjs. Run it against any clip and you should get comparable numbers back.