Lottie vs GIF vs MP4: Which Animation Format Should You Actually Use?

This is the least glamorous decision in motion design and the one that does the most damage when it goes wrong. The same five-second animation can weigh 26 MB or 40 KB depending on nothing but the format you exported it as. Your users feel that difference before they ever notice the easing.

Here is how the three formats actually behave, and a rule you can apply in ten seconds.

Why the size gap is so extreme

The three formats store completely different things, which is the whole story.

• GIF stores pixels, frame by frame, capped at a 256-colour palette with only on-or-off transparency. No compression across frames worth the name. It was designed in 1987 and it shows.
• MP4 / WebM stores pixels too, but with modern inter-frame compression — it only encodes what changed between frames, which is why video beats GIF at the same visual quality every single time.
• Lottie stores instructions, not pixels: shapes, paths, keyframes, transforms as JSON that a player renders live. Nothing is baked, so it stays sharp at any size and any pixel density.

The numbers that follow from that are not marginal. A smooth animation that lands as a multi-megabyte GIF can be a few kilobytes as Lottie — commonly around 10× smaller than the same piece as GIF or MP4, and in extreme cases a 100 MB video becomes an 800 KB to 2 MB Lottie. Even staying in raster land, a 1 MB GIF typically becomes a roughly 150 KB WebM at equal or better quality.

A real example from this website

One of our own blog posts was shipping a 25.8 MB optimised GIF as its hero. Optimised, allegedly. We re-encoded the same animation as WebM with a poster frame: 942 KB. Same animation, same visual quality, roughly 96% lighter, and the page went from painful on mobile data to instant.

Nobody had done anything stupid. The GIF was just the default that came out of the pipeline. That is how most of these problems happen.

Side by side

When Lottie is the right answer

• Icons, loaders, toggles, success and error states, empty states.
• Illustrated onboarding and feature moments.
• Anything that must stay crisp on a 3× display or resize with the layout.
• Anything you may want to recolour, pause, restart or scrub from code later.

How to keep a Lottie actually light

Lottie is not automatically small. It is small when it is built to be.

• No embedded raster images. A PNG sequence inside a JSON is a GIF in a costume.
• Avoid effects the format does not support — blurs, mattes, expressions-heavy rigs, giant masks. They either bloat the file or silently break.
• Reduce path points and precompose sensibly; simplify before you export, not after.
• Ship .lottie (dotLottie) when your player supports it — it is a zipped bundle and lands noticeably smaller.

When video is the right answer

Use MP4 or WebM the moment your animation stops being vector. Screen recordings, camera footage, 3D renders, heavy gradients, particles and grain all compress far better as video than they will ever describe as JSON.

Practical notes we apply on every build:

• Serve WebM (VP9) first with an MP4 (H.264) fallback. WebM is usually smaller; MP4 keeps older Safari and odd in-app browsers happy.
• Autoplaying background motion needs muted, loop, playsinline and preload chosen deliberately — not auto everywhere.
• Always ship a poster image. It is what the user sees during the first moments and it protects your LCP score.
• If you need transparency, WebM with an alpha channel works. MP4 will not save you.

When GIF is still legitimate

Two cases, and they are narrow. First, email — no mail client runs a Lottie player and video support is unreliable, so a small, short, palette-reduced GIF is genuinely the right call. Second, throwaway content in chat and social where quality does not matter and convenience does.

Everything else — product UI, landing pages, documentation, app stores — has a better option. If a GIF is in your build because it was easier at export time, that is a bug with a file extension.

The ten-second rule

• Is it vector art? → Lottie.
• Is it footage, a screen recording or 3D? → WebM with an MP4 fallback.
• Is it going inside an email? → GIF, short and small.
• Does it need to respond to the user or to app state? → neither — you want Rive.

Frequently asked questions

Is Lottie always smaller than a GIF?

For vector animation, effectively always — often by an order of magnitude. If your Lottie is heavier than the GIF, it almost certainly contains embedded raster images or unsupported effects.

Does Lottie hurt performance because it renders live?

Rarely, at sane volumes. The player is roughly 60 KB gzipped and the render cost is small for a handful of animations. If you are running twenty at once on one screen, look at Rive instead.

WebM or MP4?

Both. WebM as the primary source, MP4 as the fallback. It is two lines of markup and it removes an entire class of bug reports.

Can I convert an existing GIF to Lottie?

Not meaningfully. A GIF is pixels; Lottie needs vectors. The animation has to be rebuilt — which is usually a good excuse to improve it.

What about animated SVG or APNG?

Both have real uses. Animated SVG is fine for simple, self-contained motion; APNG solves GIF’s colour and alpha limits but stays heavy. Neither has Lottie’s tooling or its cross-platform support.