MP4, WebM or GIF? Picking the right video format

Toolkit Guides · Updated July 2026 · 7 min read

Every clip you send or embed ends up wrapped in one of three formats: MP4, WebM or GIF. Most people treat the choice as a technicality — until a video refuses to send, an embed won't play on someone's phone, or a five-second loop arrives weighing 20 MB. The three aren't interchangeable; they were built for different jobs. MP4 is the one that plays everywhere, WebM trades compatibility for efficiency on the web, and GIF isn't really a video format at all — which, strangely, is exactly why it's still useful. Here's what's inside each, what the same clip costs in file size, and which one to pick for a message, a website, a social post or an email.

A format is a container plus a codec

A video file is two separate decisions traveling under one name. The container is the box — the part the file extension names. It interleaves a video track, an audio track and some metadata (duration, subtitles, the index that lets you skip ahead) into one file. The codec is the compression scheme used on the tracks inside the box, and it — not the extension — is what determines whether a given device can actually play the thing.

In practice the pairings are stable. MP4 almost always carries H.264 video with AAC audio. WebM carries VP8 or VP9 video with Vorbis or Opus audio. The split explains a classic mystery: a file “is an MP4” yet won't play on an older TV. MP4 is allowed to hold newer codecs like HEVC or AV1, so the device recognizes the box but can't decode the contents. When someone asks you for “an MP4,” what they nearly always mean is the safe pairing — H.264 plus AAC. (MDN keeps a full catalog of which containers hold which codecs if you enjoy the fine print.) GIF sidesteps the whole system: it's an image format from 1987 that happens to allow multiple frames — no tracks, no codecs, no audio.

MP4: the default that plays everywhere

MP4 — MPEG-4 Part 14, a container descended from Apple's QuickTime format — earned its dominance the boring way: hardware. Essentially every phone, laptop, TV and set-top box built in the last decade ships with a chip that decodes H.264 in silicon, so playback is smooth and cheap on battery. Every operating system, browser, editing app and messaging service accepts it. It is the closest thing digital video has to a universal donor, and it should be your default for anything that leaves your hands.

Toolkit's video converter writes exactly this pairing — H.264 video with AAC audio — and moves the file's index to the front (“faststart”), so a browser can begin playing the clip before it has finished downloading.

WebM: great on the web, patchy off it

WebM was released by Google in 2010 as a royalty-free alternative — no per-device patent licensing — which is why browser makers embraced it. Technically it's a trimmed-down cousin of the Matroska (.mkv) container, holding VP8 or VP9 video (AV1 in newer files) with Vorbis or Opus audio. Every modern browser plays it, and the newer codecs are genuinely more efficient: at comparable visual quality, a VP9 file often comes out 20–40% smaller than its H.264 equivalent. If you serve video to thousands of visitors, that's real bandwidth money.

Step outside the browser and the story flips. QuickTime won't open a WebM, an iPhone's camera roll won't import one, and plenty of TVs, car head units, older editors and chat apps either refuse it or fall back to slow, battery-hungry software decoding. WebM is the right choice when you control the player — a <video> tag on your own site — and the wrong one for sending to a human being. (Toolkit's converter writes VP8 with Vorbis audio: VP8 encodes far faster than VP9, which matters when the encoder is a browser tab rather than a server farm.)

GIF: technically terrible, occasionally perfect

Judged as video technology, GIF is indefensible. Each frame can use at most 256 colors — fine for 1987 line art, brutal for real footage, which is why GIFs of video look faintly posterized. There is no audio track, and no way to add one. And its compression (LZW, applied frame by frame) has no real concept of motion: its one economy is redrawing only the rectangle that changed since the last frame. Modern codecs predict how blocks of pixels move between frames and store just the differences; GIF stores wallpaper. The result is files an order of magnitude larger than the same clip as MP4, at visibly lower quality.

And yet. A GIF behaves like an image: it renders anywhere an <img> works, autoplays without asking permission, loops forever, and carries no play button, scrub bar or player chrome. It survives in places that strip video embeds — documentation, wikis, READMEs, issue trackers, email. That is the niche keeping it alive: a three-second silent loop that must animate the instant it's seen. Tellingly, most large platforms now convert uploaded “GIFs” into looping MP4s behind the scenes; the format survives more as an idea than as a technology.

Two rules follow. Real footage should never ship as a GIF. And a GIF should be short and small — a few seconds at a modest frame size — or the file balloons. (For a single-frame image, GIF lost to PNG long ago; Toolkit's image converter reads static GIFs and writes PNG, JPG or WebP.)

The same clip, three ways

	MP4	WebM	GIF
Typical contents	H.264 video + AAC audio	VP8/VP9 video + Vorbis/Opus audio	256-color frames, no audio
Plays on	Effectively everything	All modern browsers; patchy in native apps and TVs	Anywhere an image renders
Size for the same clip	Baseline	Often 20–40% smaller (VP9)	Often 5–20× larger
Autoplay	Where allowed, usually muted	Where allowed, usually muted	Always, everywhere
Best for	Sending to people, storing, social uploads	Embeds on sites you control	Tiny silent loops

Size is easy to estimate because it's nothing more than bitrate × duration. A 1080p H.264 clip at a healthy 5 Mbps costs about 37 MB per minute; 720p at 2.5 Mbps about 19 MB per minute; the AAC audio inside adds a modest ~1.4 MB per minute at 192 kbps. GIF plays by different rules: even sampled down to 12 frames per second and 480 pixels wide — the settings Toolkit's converter uses to keep GIF output sane — a ten-second loop routinely lands in the single-digit megabytes. That's several times the size of the same ten seconds as MP4, despite having a fraction of the frame rate, no sound and 256 colors.

See it on your own clip: drop one short video into the video converter three times — once each as MP4, WebM and GIF — and compare the output sizes. It runs FFmpeg compiled to WebAssembly in your browser, so nothing is uploaded while you experiment.

Pick by destination

Text message (iMessage, WhatsApp, RCS): MP4 with H.264 and AAC, no exceptions. Messaging apps recompress video aggressively, and plain MMS can cap attachments at about a megabyte, so send a short clip rather than a masterpiece. WebM support in messaging apps is a coin flip; don't gamble with someone else's phone.
A website you control: either MP4 alone, or WebM with an MP4 fallback — a <video> element accepts multiple <source> entries and the browser plays the first one it can decode. Make sure the MP4 is “faststart” so playback begins while the file is still downloading.
Social platforms: upload the highest-quality MP4 you have and let the platform re-encode it — it will regardless. Compressing hard before upload just hands their encoder worse material to work from.
Email: mail clients don't play embedded video. Attach a small MP4 (Gmail caps attachments at 25 MB), or embed a short GIF as a silent preview that links out to the full video — knowing that some older Outlook versions show only its first frame. And if the sound is the part that matters, don't send video at all: extract the audio and attach a file a tenth the size.

The bottom line

Convert with a purpose, or don't convert. Every lossy-to-lossy conversion re-compresses the picture and costs a little quality, so a clip that already plays where it needs to play should be left alone. The conversions genuinely worth doing: something exotic (MKV, WMV, an odd MOV) into MP4 for sending; MP4 into WebM only when you're serving enough traffic for the bandwidth savings to matter; MP4 into GIF only for a seconds-long silent loop that has to autoplay. If you remember one line, make it this: MP4 to send, WebM to embed, GIF only when it must move without asking.