Animated GIF, WebP, or Video: Which to Use

Why GIF files are so large

GIF predates the web and its constraints show. Each frame is limited to a palette of 256 colours, so photographic content has to be reduced drastically — which is why gradients in a GIF show visible banding and why a video clip converted to GIF looks posterised.

More importantly, GIF's compression barely exploits the relationship between frames. Video codecs achieve their enormous savings by storing one complete frame and then describing only what changed in the frames that follow, which for typical footage is a small fraction of the picture. GIF has only rudimentary support for this and compresses each frame largely on its own.

The combined result is that a few seconds of motion routinely produces a file of several megabytes, while the same clip encoded as modern video is a few hundred kilobytes and looks better. This is not a tuning problem; it is a thirty-five year gap in compression technique.

Transparency in GIF is also crude: each pixel is either fully transparent or fully opaque, with no intermediate values. Edges are therefore jagged unless the artwork was designed around the limitation.

What video gives you instead

MP4 with the H.264 codec is the safest video choice — decoded by essentially everything, frequently in hardware, which matters for battery life on phones. WebM with VP9, and MP4 with AV1, compress better still but have narrower support and cost more to encode.

For a web page, a video element set to autoplay, loop, muted, and playsinline behaves like an animated image: it starts on its own, repeats, and plays inline rather than taking over the screen. The muted attribute is not optional — browsers block autoplay with sound, and omitting it is the usual reason an autoplaying video silently fails to start.

The practical gain is substantial. The same clip that is four megabytes as a GIF is commonly a few hundred kilobytes as MP4, with smooth motion and full colour rather than banded 256-colour frames.

The cost is that a video is not an image. It cannot be pasted into a chat that accepts only images, embedded in an email, or dropped into a document the way a GIF can. That limitation, rather than any technical merit, is what keeps GIF alive.

Animated WebP as a middle path

WebP supports animation and does it far better than GIF: full colour rather than a 256-entry palette, proper alpha transparency with intermediate values, and compression that does exploit similarity between frames.

It remains an image rather than a video, which means it works in an image element, needs no player, and is handled by tooling that expects images. For a decorative loop or a short interface animation with transparency, it is frequently the best available answer.

Support in current browsers is broad. Support elsewhere is patchier — some chat applications, email clients, and older desktop software still do not handle animated WebP, and an upload form's accepted-format list may predate it entirely. Check the destination before committing.

Note that converting an animated WebP to PNG, as PixelConvert does, keeps only the first frame. A still PNG has nowhere to put the remaining frames, and the result page reports this rather than producing a silent still.

Choosing for your actual situation

A short product or feature demo on your own website: video. It is the largest file of the three options in raw terms and the smallest once encoded properly, and you control the markup.

A decorative background loop: video, muted and autoplaying, or animated WebP if it needs transparency. Keep it short and consider whether it earns its bandwidth at all.

A reaction clip in a chat application or social platform: whatever the platform accepts, which is often GIF. Many platforms now transcode uploaded GIFs to video behind the scenes, so you get the bandwidth benefit regardless of what you uploaded.

An animation inside an email: this is GIF's last genuine stronghold. Email clients broadly do not play video, and support for animated WebP is unreliable. Keep the file small, and design the first frame to work as a still, because some clients show only that.

A UI animation such as a spinner or a state transition: none of these. Use CSS or SVG animation, which is a fraction of the size, scales cleanly to any density, and can be paused or disabled by the user.

A screen recording for a bug report: video, or a series of still screenshots. A GIF of a screen recording is both large and hard to pause at the moment that matters.

Making an animation smaller

The reliable savings come from removing content rather than from tuning an encoder. Shorten the clip — most animations are longer than they need to be, and trimming a five-second loop to two is a straightforward 60% saving. Reduce the dimensions to the size it will actually display at. Lower the frame rate; many animations look fine at 15 frames per second and some at 10.

Crop to the region that moves. If only one corner of the frame is animated, the rest is being re-encoded repeatedly for no reason.

Simplify the content. A clip with a static background and one moving element compresses far better than a clip where the camera moves, because everything changes between frames when the camera does.

If you must ship GIF, reduce the palette deliberately rather than letting a converter choose. Flat graphics with few colours can drop to 64 or 32 palette entries with no visible change and a meaningful size reduction; photographic content cannot.

Motion, accessibility, and courtesy

Animation that plays automatically and repeats indefinitely is a genuine accessibility problem, not a stylistic preference. It is distracting for readers with attention difficulties, and rapid movement or flashing can trigger physical symptoms including seizures.

Accessibility guidance is specific about this: content that moves or auto-updates for more than a few seconds needs a mechanism to pause, stop, or hide it. A video element with controls satisfies that; an endlessly looping GIF with no controls does not.

Operating systems expose a reduced-motion preference, and it is straightforward to honour it — serve a still image instead of the animation when the reader has asked for less movement. Respecting that setting costs very little and matters a great deal to the people who set it.

Avoid anything that flashes more than about three times per second, which is the widely used threshold for seizure risk. This applies to decorative animation just as much as to content.