Animated GIF vs video: which one you actually want

If you are putting a moving image on a web page, use a video file. A muted, looping, autoplaying MP4 or WebM looks the same to the viewer as a GIF, weighs a fraction as much, and can be paused. That is the answer for the large majority of cases, and the rest of this explains why the gap is so wide and where the exceptions genuinely are.

They do still exist. GIF survives in email, in places that block video, and in tiny flat-coloured loops where its weaknesses never come up. Knowing which situation you are in takes about thirty seconds once you know what the format is actually doing.

GIF is a 1987 format and it shows

The Graphics Interchange Format was published by CompuServe in 1987, with the animation-capable revision arriving in 1989. It was designed for the graphics of that era: logos, icons, simple illustrations, screens of flat colour, delivered over dial-up.

Two design decisions from then define everything about how it behaves now.

It is an indexed-colour format. A GIF frame does not store red, green and blue values per pixel. It stores a palette of at most 256 colours and then, for each pixel, an index pointing into that palette. A full-colour photograph contains vastly more distinct colours than that, so converting one to GIF means throwing nearly all of them away and approximating the rest.

Its compression is lossless and one-dimensional. GIF uses LZW, a dictionary compressor that finds repeated sequences of palette indices. Give it a run of identical pixels and it collapses them to almost nothing. Give it pixels that keep changing slightly, which is what any photographic content looks like, and the dictionary never gets traction.

There are a few smaller limitations worth knowing. Transparency in GIF is a single palette entry marked as transparent, so a pixel is either fully opaque or fully invisible, which is why GIF cutouts have jagged edges. There is no audio at all. And colour depth is capped at 8 bits per pixel of index data, with no way to carry the wider gamut or higher bit depth that modern displays can show.

Why photographic GIFs get so large

The interesting part is that the 256-colour limit does not just degrade quality. It actively makes the file bigger, and that surprises people.

Here is the chain. To make a photograph look acceptable in 256 colours, encoders use dithering: scattering pixels of the available colours in patterns that blend into the missing shades when viewed from a distance. Dithering is, structurally, noise. It takes areas that were smooth and fills them with alternating, near-random pixel values.

LZW compression depends on finding repetition. Dithered noise is the opposite of repetition. So the technique used to make the image look better is the technique that destroys the compressor's ability to shrink it. You get a worse-looking image in a bigger file, from the same source.

Then multiply by frames. GIF has no concept of motion. It can skip storing parts of a frame that are identical to the previous one, using a rectangular region and a disposal method, and good encoders lean on this hard. But if the whole frame changes even slightly, which happens with any camera movement, any noise, any fade, that optimisation collapses and you are storing something close to a complete new image for every frame.

What video codecs do instead

A modern video codec attacks the same problem from a completely different direction, and the key idea is motion compensation.

Rather than storing each frame, the encoder stores occasional full keyframes and then, for the frames in between, a description of how blocks of the previous frame moved and what small differences remain. If a person walks across a static background, the background is essentially free after the first frame, and the person is described as a set of displaced blocks plus corrections.

On top of that, video codecs are lossy in the same way JPEG is. They convert blocks into frequency components and discard the high-frequency detail your eye is least sensitive to. They also subsample colour information, because human vision resolves brightness far more finely than colour. And they carry full 24-bit colour, so no palette reduction and no dithering is needed in the first place.

H.264 is the codec that plays essentially everywhere, in an MP4 container. VP9 and AV1 compress noticeably better and are widely but not universally supported, which is why the common pattern is to offer a WebM source with an MP4 fallback and let the browser pick.

How big is the difference, honestly

You will see the claim that a GIF is ten times the size of the equivalent video, and for a typical few-second photographic clip that is a fair description of the magnitude. It is not a fixed ratio and anyone quoting one precisely is overselling it.

What actually drives the gap:

• Content type. Real footage, with grain and gradients and camera movement, is where GIF does worst and video codecs do best. The gap here is large, comfortably an order of magnitude and sometimes far more.
• Length. GIF cost grows close to linearly with frames. Video cost grows with new information, so a longer clip of similar motion gets relatively cheaper per second. The longer the clip, the wider the gap.
• Motion. A locked-off shot where only a small area moves is the best case for both formats, and the one case where a well-optimised GIF is not embarrassing.
• Flat graphics. A simple animation of a few solid colours is GIF's home turf. The gap narrows a lot, and at very small sizes the video container's own overhead starts to matter.

You can see the effect without any benchmarking. Take any GIF you have and note its size, then note that a video file of similar dimensions and length would fit comfortably inside it several times over. The mechanism above tells you why before you measure anything.

Autoplay: the reason GIF lasted this long

For years GIF had one genuine advantage that had nothing to do with compression. It sits inside an <img> tag. It plays immediately, loops forever, needs no player, no controls, no JavaScript, and works in any context that accepts an image.

Video used to be awkward in comparison, particularly on mobile, where browsers refused to autoplay and often took the video fullscreen when it did play. That is no longer true. The modern equivalent is a video element marked as muted, looping, autoplaying and playing inline, and browsers allow it precisely because it is silent.

The important detail is the muted part. Browsers block autoplay of anything with sound, by policy, and will keep doing so. A GIF replacement has no audio track anyway, so that restriction costs you nothing.

Two practical extras you get from using a video element. You can supply a poster image so something sensible is visible before the file loads, and you can control loading behaviour so a heavy animation below the fold does not compete with the rest of the page. A GIF gives you neither: it downloads in full and starts playing whether or not anyone will ever scroll to it.

Accessibility, where GIF is genuinely a problem

This is the part that usually gets skipped and it is the strongest argument against GIF.

Motion cannot be stopped. An animated GIF loops forever with no way for the viewer to pause it. Accessibility guidance is explicit that moving content lasting more than a few seconds needs a mechanism to pause, stop or hide it, because persistent motion is genuinely disabling for some people: it interferes with reading, and it can trigger nausea or migraine in people with vestibular disorders. A video element gives you controls for free, and lets you respect the operating system's reduced-motion preference by not autoplaying at all for people who have asked for less animation.

Flashing content is a safety issue. Rapid flashes can trigger seizures. That applies to both formats, but GIF's culture of short, punchy, high-contrast loops makes it the more common offender, and again, the viewer cannot stop it.

There is no way to caption a GIF. Video carries caption tracks and descriptive audio. A GIF has no track of any kind, so any information conveyed in the motion has to be described in the alt text or the surrounding copy. If a GIF is showing a process, someone using a screen reader gets whatever you typed in the alt attribute and nothing else.

Where GIF is still the right answer

Not everywhere accepts video, and in those places the size argument is irrelevant because video is not an option.

Email. This is the clearest case. Video in email is effectively unsupported outside a couple of clients, while animated GIF plays in most of them. The one thing to plan for is that Outlook on Windows has long shown only the first frame of an animated GIF, so design that first frame to work as a still image on its own. Assume a meaningful share of your recipients will only ever see it.

Contexts that only accept images. Wikis, some forums, some documentation platforms, some chat tools, some CMS fields. If the upload field takes an image and nothing else, GIF is the only moving format that goes through.

Very small flat-colour loops. A spinner, a tiny UI demo of flat interface elements, a simple diagram animating between two states. Few colours, hard edges, no dithering needed, and LZW handles it well. At that scale the difference is not worth engineering around.

The reaction-image ecosystem. Whole platforms and keyboards are built around GIF as the interchange currency. Fighting that is pointless, and in practice several large platforms silently transcode uploaded GIFs to video on their end anyway, which is a decent hint about how good the format is at its own job.

The middle grounds: APNG, WebP and animated AVIF

Between GIF and real video there are formats that keep the drop-into-an-image-tag convenience while fixing GIF's worst limitations.

APNG is the natural upgrade when you need smooth transparent edges over an unknown background, which GIF simply cannot do. It is lossless, so it stays large for photographic content, but for flat UI animation it is often smaller than the GIF and looks considerably better.

Animated WebP is the best all-round compromise for something that must live in an image tag: full colour, real alpha, lossy compression, and support across all current browsers. It is still not as efficient as a proper video codec on a long clip, because it lacks the full motion-prediction machinery, but against GIF it is not close. If you are weighing up the still-image versions of these formats too, the JPG, PNG and WebP comparison covers that side.

Animated AVIF compresses best of the three but has the least mature tooling and the narrowest support, so treat it as something to serve with a fallback rather than as your only copy.

If you have to ship a GIF, make it a small one

When the destination leaves you no choice, the levers are all about giving LZW less to store.

• Cut the dimensions. This is by far the biggest lever, because cost scales with pixel count on every frame at once.
• Cut the frame rate. Ten to fifteen frames per second is usually enough for a short loop and can nearly halve the file compared with source frame rate.
• Cut the length. Find the shortest section that makes the point, and trim aggressively.
• Shrink the palette. You rarely need the full 256. Dropping to 64 or 128 colours often costs less visually than the size saving is worth.
• Reduce or disable dithering on flat-coloured content. On photographic content you usually need it, which is a sign you should not be using GIF.
• Crop to what moves. Static borders are cheap but not free, and a tighter crop lets you keep more resolution where it matters.

Worth being straight about what our own tools do and do not do here: the image converter reads an animated GIF's first frame and turns it into a still JPG, PNG, WebP or AVIF, which is exactly what you want for a thumbnail, an email fallback, or a poster image for a video. It does not keep the animation, and it does not produce video files. For turning a GIF into an MP4 or the other way round, you need a video tool.

Deciding in thirty seconds

Run through it in order.

1. Is it going in an email? GIF, with a first frame that stands alone.
2. Does the destination accept only images? Animated WebP if it is supported there, GIF if not.
3. Is it on a web page you control? A muted, looping, inline-playing video with a poster image. This is the default and it is not close.
4. Is it a tiny flat-colour loop, a few kilobytes either way? Use whatever is convenient. The engineering is not worth it.
5. Does the motion convey information someone might need described? Video, so you can caption it, and describe it in the surrounding text either way.

The one thing not to do is upload a several-megabyte photographic GIF to a web page because it was easy. That is the case where the format costs you the most and gives you the least: a larger file, fewer colours, visible dithering, no pause control and no captions, in exchange for saving yourself five lines of markup.