GIF vs WebP vs MP4: Measured Numbers and a Decision Rule
A 4-second reaction clip weighs 3.5 MB as a GIF, 380 KB as an animated WebP, and 210 KB as a muted MP4. Those are measured numbers from the same source video, exported in August 2026 with default settings in each encoder. The GIF is not a little heavier; it is an order of magnitude heavier, and that gap shapes every decision about which format to ship.
The catch is that GIF still wins the one metric that matters most in some contexts: it plays literally everywhere. Choosing between the three is a question about where your loop will live, not about which codec is best in the abstract.
Where each format came from
GIF dates to 1987 and encodes frames as palette-limited bitmaps with LZW compression. Animated WebP arrived in 2010 as an extension of Google's WebP still format, carrying full 24-bit color, alpha transparency, and both lossy and lossless modes. The MP4 loop is not an image at all: it is an H.264 or H.265 video in a container, played with the muted, autoplay, loop, and playsinline attributes to impersonate a GIF.
Quality per kilobyte
WebP's lossy mode uses VP8 keyframe compression, the same family as modern video codecs, so it predicts motion between frames instead of storing each frame whole. That is where the 8–10x size advantage comes from. GIF stores every frame independently with a 256-color cap, so smooth motion and photographic content punish it twice: once in size, once in visible banding.
MP4 goes further with inter-frame prediction and decades of hardware decoding support. A 1080p loop that would be unusable as a 30 MB GIF plays as a 1.2 MB MP4 with battery-friendly hardware decode on any phone sold since 2015.
The compatibility reality in 2026
Animated WebP works in every current browser, Slack, Discord, Telegram, and most CMS editors. It fails in older email clients, many forum engines, Microsoft Office, and a long tail of enterprise software that validates uploads by file signature. MP4-as-GIF fails anywhere that only accepts image uploads: avatars, comment systems, GitHub READMEs rendered in restricted contexts. GIF fails nowhere, which is why it remains the fallback of the entire internet.
- Documentation and READMEs: GIF, because GitHub and friends sanitize video tags
- Your own website: MP4 loop, with WebP as the image-format alternative
- Email marketing: GIF under 1 MB, the only format email clients animate reliably
- Discord and Slack custom emoji: either, but WebP keeps you under size caps
- App store screenshots with motion: MP4, required by both Apple and Google
| Test clip, 4 s at 480 px | GIF | Animated WebP | MP4 (H.264) |
|---|---|---|---|
| File size | 3.5 MB | 380 KB | 210 KB |
| Colors | 256 per frame | 16.7 M + alpha | 16.7 M |
| Plays in Outlook desktop | first frame only* | no | no |
| Plays in 2005-era software | yes | no | no |
| Hardware decode on phones | no | no | yes |
*Outlook's Word-based renderer shows the first frame of a GIF and animates nothing; every competitor does the same or worse with the other two formats.
A decision rule you can reuse
Ask one question: does an image tag have to carry this? If yes, the answer is GIF for maximum reach or WebP when you control the audience's software. If no, serve an MP4 loop and stop paying the GIF tax. The worst outcome is the common one: shipping a 5 MB GIF on your own landing page where a 300 KB video would load faster, look sharper, and cost less bandwidth on every visit.
