MP4 vs WebM vs GIF in 2026 — the practical guide for product engineers

The "which video format" question used to have a complicated answer involving fallbacks, codec capability detection, and a <video> element with three <source> children. In 2026 the answer is mostly "MP4," with two specific exceptions where you should reach for WebM or GIF instead.

Here is the current state, written for product engineers shipping video on a website, in an app, or as a downloaded asset.

TL;DR

That's 80% of decisions. The rest of the post unpacks the edge cases.

Where the formats stand in 2026

MP4 / H.264 — the universal baseline. Every browser, every editing tool, every social platform. Hardware-decoded on every device made in the last decade. Lossy but tunable; modern encoders get to visually-lossless at ~6 Mbps for 1080p.

MP4 / H.265 (HEVC) — ~30% smaller than H.264 at equivalent quality. Now broadly supported in browsers but still has licensing complexity for batch production. Use for archival, skip for web embed.

WebM / VP9 — Google's royalty-free codec. Supported in every major browser except for Safari edge cases. Compression is competitive with H.265. The only browser-playable format that supports alpha channels.

WebM / AV1 — the newer royalty-free codec. Better compression than VP9. Hardware decode is now common in mid-range hardware. Use for high-volume video where bandwidth dominates cost.

GIF — 256 colors, no audio, no codec, file sizes that embarrass everyone. Still the only motion format that renders in-line in email clients. Use only when you have to.

When you actually need WebM

One reason, mostly: transparency. If you need a video with an alpha channel (a character animation that drops onto an arbitrary background, a product shot with the background already cut out), WebM with VP9 and an alpha layer is the only browser-playable option.

The encoding command, roughly:

ffmpeg -i input-with-alpha.mov \
  -c:v libvpx-vp9 -auto-alt-ref 0 \
  -pix_fmt yuva420p \
  -b:v 2M \
  output.webm

Two flags matter: -auto-alt-ref 0 (alpha videos break with alt-ref frames) and -pix_fmt yuva420p (the alpha-aware pixel format).

In HTML:

<video autoplay muted loop playsinline>
  <source src="overlay.webm" type="video/webm">
</video>

No MP4 fallback — there is no MP4 with alpha that browsers play. If you need a fallback, render a separate composited MP4 onto the expected background.

When you have to use GIF

One reason: email. Every major email client (Gmail, Outlook, Apple Mail, every B2B mailer) renders animated GIFs in-line. None of them render video.

Rules for email GIFs:

• Cap file size at 1 MB. Outlook truncates animations past ~1.2 MB to the first frame.
• First frame is critical. Many clients show only the first frame on initial open. Make it a complete, readable image.
• 6 seconds is the practical ceiling. Past that, file size goes up faster than engagement does.

The dithering workflow that produces good GIFs from an MP4 source:

ffmpeg -i input.mp4 -vf "fps=12,scale=600:-1:flags=lanczos,split[a][b];[a]palettegen[p];[b][p]paletteuse" out.gif

The palettegen + paletteuse pass gives you a per-clip optimized palette, which cuts file size by 40-60% compared to the default. Run it.

Autoplay rules (the thing that bites everyone)

Every browser blocks autoplay for videos with audio. The rule is:

• muted + playsinline + autoplay = plays automatically.
• Audio present = waits for user interaction.

For hero-loop video on a landing page, always render silent and let the user unmute if they want.

<video autoplay muted loop playsinline>
  <source src="hero.mp4" type="video/mp4">
</video>

All four attributes matter. Drop playsinline and iOS will full-screen-takeover the video.

File size targets

For a typical landing-page hero loop (8 seconds, 1920×1080, no audio):

The numbers are representative, not authoritative; bitrate tuning shifts each by ±20%. The shape is what matters: MP4 / H.264 is the right size-to-quality tradeoff for 95% of cases, and AV1 is the future for high-volume delivery.

When MP4 H.265 is worth the friction

Two cases:

1. You ship a lot of video and CDN cost matters. 30% smaller files compound across millions of plays.
2. You ship to mobile and bandwidth-sensitive markets. The compression delta is the user experience.

For everything else, the licensing complexity of H.265 outweighs the file-size win.

The deterministic render question

HyperFrames defaults to MP4 / H.264 for output because it's the format the receiving editor / browser / platform actually wants. If you need WebM with alpha (for an overlay product) or batch AV1 (for CDN cost), both are flag-flips on the render command.

The render pipeline is format-agnostic past the frame-capture step — the same frames composite to any of the five formats above.

Practical recommendations

• Default to MP4 / H.264 unless you have a reason not to.
• Reach for WebM only for alpha.
• Reach for GIF only for email.
• Reach for H.265 / AV1 only when CDN cost dominates.

Most of the time, the answer is one format. Pick it, render it, ship it.