MP4 vs WebM vs GIF: which screen recording format should you use in 2026?

Pick the wrong format for a screen recording and one of four things happens: the file is too big for the channel you're sending it to, the receiver can't autoplay it inline, the quality looks soft on retina, or — worst — you ship a 14 MB GIF when a 280 KB MP4 would have looked identical. This post is the decision tree we actually use when exporting from ClearRec, with the bitrate math, the real file sizes from our test clip, and the honest reasons one format wins over another in 2026.

TL;DR — the one-table answer

The rest of this post is the why. Skip to "The decision tree" if you just want the flowchart.

The three formats, in one paragraph each

MP4 (H.264 / AAC). A container format from 2003 that almost always carries H.264 video and AAC audio. The combination is the lingua franca of consumer video — every browser since 2012, every phone since 2010, every chat app, every CMS. H.264 is patented but the licensing is essentially "everyone has already paid", so support is universal. In 2026 it's still the safe default for anything you're sending to a human.

WebM (VP9 / Opus, sometimes AV1). A container Google introduced in 2010 that pairs the royalty-free VP9 video codec with the Opus audio codec. At the same perceptual quality as H.264 it's roughly 30-40% smaller, and AV1 (the successor inside the same container) is another 20-30% smaller again. The catch is that legacy contexts — old Slack desktop builds, some email clients, third-party CMS embed widgets — will quietly fail to play it. WebM is the right call when you control the playback context (your own site, your own docs).

GIF (Graphics Interchange Format, 1987). A 256-color, palette-indexed animation format that predates the web by two years. It has no audio, no alpha blending beyond binary transparency, no compression scheme designed for video, and it is enormous for what it gives you. Despite all of that, it's still the only animated format that renders inline in GitHub READMEs, in some webhook previews, and in a handful of stubborn chat clients. We didn't pick it; it picked us.

Same recording, three exports — real numbers from ClearRec

Here's a single 12-second screen recording, captured at 1080p / 30 fps in ClearRec's "Medium" quality tier (5 Mbps), then exported three ways. The clip is a real product demo — a UI walk-through with a cursor, text input, and one modal open/close. No music.

The MP4 is fifteen times smaller than the GIF. The WebM is twenty-two times smaller than the GIF. And both video files look better. This is the entire reason we put a warning on the GIF export panel: it's almost always the wrong default. The only time it's the right answer is when the destination renders Markdown but not HTML5 video — which in practice means GitHub README files and one or two long-tail wikis.

The same clip at our default Ultra tier (1440p / 60 fps / 20 Mbps) comes out to roughly:

• MP4: 2.1 MB (still attaches to a GitHub PR with no friction)
• WebM: 1.4 MB
• GIF at 1440p: 38 MB (and unwatchable — please don't do this)

If you take one number away from this post: a GIF is on average ~15× the size of the equivalent MP4 for screen-recording content. Bandwidth is cheap, but inbox-friendly is cheap and respectful.

H.264, VP9, AV1 — what changed by 2026

Codecs are the part of "video format" that actually does the compression. The container (MP4, WebM) is just a wrapper that tells the player which codec to invoke. Three codecs matter in 2026:

H.264 (a.k.a. AVC)

• Released: 2003.
• Hardware decode: every consumer device shipped since ~2010.
• Encode speed in software: very fast (libx264 on a 2023 laptop encodes 1080p screen content faster than real-time).
• Browser support: 100%.
• Why it still wins in 2026: nothing else has the same "it just plays" coverage. When you don't know what's on the other end, ship H.264.

VP9

• Released: 2013.
• Hardware decode: shipped on most consumer SoCs since ~2018.
• Compression vs H.264: roughly 30-40% smaller at the same perceptual quality, on screen content.
• Browser support: Chrome, Firefox, Edge, Safari 14+ (which is now everywhere).
• Why we use it: ClearRec's WebM export is VP9. For developers embedding video on their own site, it's the sweet spot between "small" and "decodes everywhere".

AV1

• Released: 2018 (royalty-free, AOMedia).
• Hardware decode: shipping on Apple M3+, Intel 11th-gen+, AMD Ryzen 7000+, recent Snapdragons, recent Tensor SoCs. Software decode works everywhere but is CPU-hungry.
• Compression vs H.264: roughly 50% smaller on the same screen content.
• Compression vs VP9: roughly 20-30% smaller.
• Why we don't make it the default in 2026: encode speed. AV1 software encode at 1080p is still ~0.3× real-time on a 2024 laptop. ClearRec runs ffmpeg.wasm inside your browser tab — we don't want to make you wait 30 seconds to export a 10-second clip. If your viewer's device can decode AV1 (most 2024-and-later phones can), and you control the player, it's a great web-embed codec.

A quick mental model: H.264 is the lowest common denominator, VP9 is the practical web default in 2026, AV1 is where the next 20% of savings is hiding. The further down the list you go, the smaller the file — and the higher the chance that someone on a five-year-old work laptop can't play it.

Why GIF is so big — the format-architectural reason

A common question we get: why is the GIF so much bigger than the video?

The honest answer is that GIF was designed in 1987 for static raster images of UI mockups and chat-room signatures. The animation extension was bolted on later, with no concept of inter-frame compression — every frame stores its full pixel grid, only deduplicated against the immediately previous frame, and constrained to a single 256-color palette. There is no motion estimation, no DCT, no transform coding, no entropy coding worth the name. It is, structurally, a stack of bitmaps in a zip file.

H.264 and VP9, by contrast, use inter-frame prediction: each frame can be encoded as a difference from previous frames (and, for B-frames, future frames), with motion vectors describing how blocks of pixels moved. For screen recordings — where 95% of pixels stay identical between adjacent frames — this is enormously effective. A 12-second screen clip at 1080p has roughly 360 frames; the H.264 encoder typically emits only 15-25 keyframes and represents the rest as motion deltas a few kilobytes each.

GIF has to send the full frame, every frame, in a 256-color palette. The math doesn't work out in its favor and never will.

That said, when GIF is the right answer (because the destination won't render anything else), there's still a wide quality gap between a good GIF and a bad one. We've written a separate post on the two-pass palettegen workflow — the same pipeline we run in the editor — that produces GIFs ~30% smaller than the default ffmpeg incantation, with cleaner color reproduction.

When MP4 wins (almost everywhere)

If you're sending a screen recording to another human, MP4 is the default. Concretely, MP4 is the right format when:

• You're attaching to a GitHub PR or issue comment. GitHub renders <video> for .mp4 uploads since 2023; the result autoplays inline, in the comment, with no upload wait. (READMEs are the exception — see below.)
• You're posting in Slack, Discord, Microsoft Teams, Notion, Linear, Jira, or Asana. All of these render <video> for MP4 attachments and autoplay the recording inline. None of them play GIFs more efficiently than MP4 — they just also accept GIFs.
• You're emailing the file. Most modern clients (Gmail, Outlook, Apple Mail) treat MP4 as a benign attachment; an unfamiliar codec inside a WebM can sometimes trip enterprise email filters.
• You're posting on X, LinkedIn, BlueSky, or Mastodon. These platforms re-encode whatever you upload, but they expect H.264 input — anything else takes a transcoding round-trip that can introduce visible artifacts.
• You're archiving the clip. H.264 has had universal hardware decode for 15 years and will be playable in 2040; AV1 might be, VP9 probably will be, but H.264 is the codec you'd put in a time capsule.

ClearRec ships H.264 + AAC inside MP4 as the default for exactly these reasons. The encoder settings we use — libx264 with --preset=fast and CRF 23, AAC at 128 kbps — are the same defaults the broader web has converged on for "good enough for almost everything".

When WebM wins

WebM is the right call in three specific situations:

1. Embedding on your own site. If you control the player, every browser since Safari 14 (2020) decodes VP9 in WebM. You'll save ~30% on bandwidth per view at the same perceptual quality. For a docs site or product tour, that's free money.
2. Sending to a known modern device. "I'm sending this to a teammate on a 2023 MacBook" — fine, ship them WebM and save the bytes.
3. Loop sources for further editing. If you're piping a clip into a real NLE (Premiere, Resolve, Final Cut), they all accept VP9-in-WebM and you skip a transcoding pass.

WebM is not the right call when you don't know what's on the other end. We've seen WebM files silently fail in legacy Slack desktop builds, in some enterprise email gateways, and in a few stubborn embed widgets that hard-code video/mp4. If the recipient says "the video won't play", the fix is always "re-export as MP4".

When GIF wins (yes, sometimes)

GIF is the right answer when the destination renders Markdown but not HTML5 video. In 2026, that means:

• GitHub README.md files. READMEs are rendered through GitHub's own Markdown pipeline, which sanitizes <video> tags but renders inline <img> for animated GIFs. If you want a moving hero clip in your project's README.md, GIF is your only option.
• PyPI, npm, and crates.io project pages. These all re-render the GitHub README and inherit the same restriction.
• A handful of long-tail wikis and forum platforms that strip everything except <img> and <a>.
• Webhook previews (Discord, Slack message previews from RSS feeds, etc.) that won't expand a <video> tag but will show a GIF as a frame.

If you're hitting GIF for any other reason — Slack, Discord, Notion, an email — switch to MP4. You'll cut the file size by ~15× and improve the visual quality at the same time.

When you do need a GIF, two settings make a huge difference:

• Cap at 15 fps. Screen recordings read fine at 15 fps. Doubling to 30 fps doubles the file size for no perceptual gain.
• Run a two-pass palettegen. The default ffmpeg GIF output picks 256 colors greedily; a palettegen=stats_mode=diff → paletteuse=dither=bayer:bayer_scale=5 pipeline weights the palette toward pixels that actually change between frames. ClearRec runs this automatically — the full breakdown is in our GIF conversion guide.

The decision tree

Here's the actual flowchart we use, in one block:

Are you sending this to a human?
├── Yes → Will it render <video>?
│         ├── Yes (Slack/Discord/Notion/Linear/Jira/GitHub PR/email) → MP4
│         └── No  (GitHub README.md, PyPI, npm) ───────────────────── GIF
└── No (you're embedding it on a site you control)
          → WebM (VP9) — 30% smaller than MP4 at the same quality

Three nodes. That's the whole decision.

Bitrate and resolution — the two knobs that actually matter

Once you've picked a format, the next two questions are how many pixels per second and how many of those pixels are bits. ClearRec exposes both through its six quality tiers, but here's the mental model:

Three quick heuristics:

• For bug reports, demos, and async dev updates: use the Ultra default. 1440p / 60 fps / 20 Mbps in MP4 ships clips at 1-3 MB per minute. Inbox-friendly, readable on a retina display, and overkill-safe for a future viewer on a 4K screen.
• For lectures and design reviews over 10 minutes: drop to High or Medium. The file size compounds linearly with length; a 45-minute Ultra recording is ~700 MB, while the same clip at Medium is ~140 MB.
• For inline GIF demos: shoot at Medium or Low. The GIF re-encode caps at 15 fps anyway, and a 720p source produces a 720p GIF that comfortably fits under Slack's 25 MB attachment cap.

If you're not sure, leave the picker on Ultra and let the export format do the heavy lifting.

Frequently asked questions

Q: Does my recipient need to install anything to play a ClearRec MP4? No. H.264 + AAC inside MP4 is the default codec stack on every browser, every modern phone, and every desktop OS. If they can watch YouTube, they can play your MP4.

Q: Why does my exported MP4 have a .mov extension on macOS sometimes? That's macOS Quick Look re-wrapping the same H.264 stream into a MOV container for preview. The underlying bytes are H.264 + AAC; if you upload the file anywhere it'll be read as MP4. ClearRec always writes .mp4 directly — if you see .mov, you're looking at a Finder preview.

Q: Is WebM safe to send to a customer? If the customer is on a 2020-and-later device, yes. If you don't know, send MP4. WebM is the right pick for known modern playback contexts and a coin-flip for unknown ones.

Q: I posted a .webm to a Notion page and it won't play. Why? Notion auto-converts uploaded videos and sometimes fails the conversion on long WebM files. The workaround is to ship MP4. Notion's own docs recommend MP4 + H.264.

Q: Can I get smaller files than MP4 without going to WebM? Yes — drop the bitrate. The Ultra tier (20 Mbps) is conservative for screen content; if you re-encode at 8-10 Mbps the file shrinks by half and the perceptual difference on screen recordings is invisible. ClearRec exposes this through the Medium and High tiers.

Q: Why doesn't ClearRec export AV1 by default? Encode speed inside ffmpeg.wasm. AV1 software encode is still ~3× slower than VP9 and ~10× slower than H.264 on the kind of hardware most viewers have. We'd rather your export finish in 4 seconds than make the file 20% smaller at the cost of a 40-second wait.

Q: What format does Loom use? Loom serves MP4 (H.264 + AAC) to viewers, regardless of what you uploaded — they re-encode server-side. Most cloud-based recorders do the same, which is one reason you're not actually choosing a format when you use them; the platform picks it for you. ClearRec gives you the choice because everything happens locally.

Q: Should I record at 60 fps or 30 fps? For screen content, 60 fps shows visibly smoother cursor movement and panel transitions, which makes a real difference on UI demos. For lectures (mostly static slides) or interview-style talking-head footage, 30 fps is fine and halves the file size. ClearRec defaults to 60 fps in the Ultra tier; drop to Medium if file size matters more than fluidity.

The honest summary

Every "MP4 vs WebM vs GIF" guide on the web in 2026 still hedges. We're going to be specific:

• MP4 (H.264) is the default, always, unless you have a good reason. It plays everywhere, looks great, and produces small files. ClearRec's Ultra tier (1440p / 60 fps / 20 Mbps) gives you ~1-3 MB per minute, which is comfortable for GitHub PRs, Slack threads, and email.
• WebM (VP9) is the upgrade for known modern playback. It's 30% smaller than MP4 at equivalent quality. Use it for your own site, your own docs, and known modern recipients.
• GIF is the legacy compatibility format. Use it only when the destination won't render <video> — in 2026 that means GitHub READMEs, PyPI / npm project pages, and a few stubborn legacy renderers. Everywhere else, GIF is the wrong answer.

If you want to try the three exports yourself, install ClearRec from the Chrome Web Store — every recording can be exported to any of the three formats from the same editor, with no upload, no re-encode round-trip, and no account.

See also

• How to convert a screen recording to GIF in Chrome — the two-pass palettegen pipeline in detail.
• The 6 best free Chrome screen recorder extensions (2026 review) — how the format choice plays out across competitors.
• The best free Loom alternative for Chrome (2026) — when MP4-as-file beats MP4-as-share-link.
• Quality tiers — all six presets with their bitrate / file-size trade-offs.
• Privacy policy — the data-flow breakdown for local-only exports.