Initializing... drag & drop files here
Supports: GIF
Animated GIF is a 1987 format that stores each frame as a 256-color palettised image and re-encodes the entire palette per frame. MP4 with H.264 stores motion-compensated, perceptually-coded video — for the same animation, the MP4 is routinely 10-20x smaller while showing millions of colours, smoother gradients, and no dithering artifacts. Almost every modern platform that accepts GIFs converts them to MP4 (or a similar codec) behind the scenes anyway; uploading MP4 directly skips a re-encoding pass and gives you control over the output.
<video autoplay loop muted playsinline> instead of GIFs. The page loads faster, scrolls smoother, and uses 80-95% less bandwidth. Browser autoplay restrictions don't apply when the audio track is muted or absent.| Property | GIF | MP4 (H.264) | WebM (VP9) |
|---|---|---|---|
| Year released | 1987 | 2003 | 2010 |
| Colours per frame | 256 (palettised) | ~16.7M (8-bit YUV) | ~16.7M (8-bit YUV) |
| Audio track | Not supported | Supported (typically AAC) | Supported (Opus/Vorbis) |
| Native loop flag | Yes (Netscape extension) | No — set via <video loop> |
No — set via <video loop> |
| Transparency | 1-bit (on/off) | None | Alpha channel (VP9) |
| Typical 5s 720p clip | 8-20 MB | 300-800 KB | 200-600 KB |
| Browser support | 100% | 96%+ | 96%+ (no Safari pre-14) |
| Best use | Sub-2s reactions, tiny pixel art | Web autoplay, social, messaging | Web autoplay where Chrome/FF dominate |
How each platform handles a GIF upload tells you whether converting to MP4 first is worth it.
| Platform | GIF cap (2026) | Auto-converts to video? | Result of uploading MP4 instead |
|---|---|---|---|
| Twitter / X | 15 MB | Yes — silent MP4 server-side | Skips re-encode, preserves quality |
| Discord (free) | 10 MB | No, kept as GIF | More room within the 10 MB cap |
| Discord Nitro | 500 MB | No, kept as GIF | Same — no benefit |
| WhatsApp (media) | ~16 MB before heavy compression | Yes — compresses heavily | Better, but still re-compressed |
| WhatsApp (as document) | 2 GB | No — file stored as-is | Recipient must tap to play |
| 20 MB | Yes — hosted video format | Skips re-encode | |
| Slack | 1 GB | No | Same — no benefit |
| iMessage | ~100 MB (no Mail Drop) | No | Smaller file, faster send |
Sources: platform help pages and a September 2024 announcement from Discord lowering the free upload cap from 25 MB to 10 MB.
The Quality Preset dropdown maps to FFmpeg's CRF (Constant Rate Factor) under the hood. Lower CRF = better quality + bigger file.
| Preset | Approx. CRF | Typical 5s 720p file size | When to use |
|---|---|---|---|
| Very High (Recommended) | 18-20 | 400-900 KB | Default — visually indistinguishable from source |
| High | 21-23 | 250-500 KB | Web embeds where size matters |
| Medium | 24-26 | 150-300 KB | Messaging, large batches |
| Low | 27-30 | 80-180 KB | Tight platform caps (older Discord free tier) |
Need a target file size rather than a quality target? Switch to Constraint Quality and set Target file size (%) directly.
No — animated GIFs cannot store audio data, so the resulting MP4 has no audio track at all (not even a silent one). Most platforms treat audioless MP4 the same way they treat GIFs for autoplay purposes, which is why browser autoplay rules let them play without user interaction. If you need sound, add it afterwards in a video editor or use MP4 to GIF for the reverse direction.
The MP4 container has no loop flag (unlike GIF's Netscape Application Extension), so looping is the player's job. On the web, add the loop attribute: <video autoplay loop muted playsinline>. Twitter, Discord, Reddit, and Slack auto-loop MP4 uploads under ~30 seconds. Standalone players (VLC, QuickTime) need loop turned on manually.
Two common reasons. First, very short GIFs (under ~1 second) have more H.264 container overhead relative to payload, so the ratio is smaller. Second, GIFs that are already tiny — 320x240, 10 fps, few colours — are already efficient for what they encode, so MP4 wins less dramatically. The 10-20x savings are most pronounced on photographic content above 480p.
MP4 plays inline in iMessage, Slack, Discord, Teams, and Telegram. In email, behaviour varies: Gmail and Outlook show the MP4 as a downloadable attachment rather than playing inline, since most email clients block embedded video. If you need an inline-playing animation in email, GIF is still the only universally-supported choice.
Stick with H.264 (the default). H.265/HEVC produces ~30-50% smaller files at the same quality, but it has weaker browser support (Safari only on the web, no Firefox/Chrome desktop without hardware decode), so it defeats the "plays everywhere" purpose. H.264 is the right answer for any GIF replacement intended for web or messaging.
GIF transparency is 1-bit (a pixel is either fully transparent or fully opaque), and standard MP4/H.264 has no alpha channel — so transparent areas get filled with a solid colour (black by default). Set the Video Background Colour option to match your page if you need white or another colour. For true alpha-channel video on the web, convert to GIF to WebM instead and use VP9 with alpha.
Yes — by default we read the source GIF's frame timing and produce an MP4 at the closest standard frame rate (most GIFs are encoded at 10, 15, 20, 24, or 25 fps). You can override this if you need a specific output fps, but matching the source avoids interpolation artifacts and judder.
Yes. Twitter/X has converted GIF uploads to silent MP4 since around 2014 and still does in 2026. Uploading an MP4 directly skips one re-encoding pass, which preserves quality (re-encoding always degrades, even slightly). It also avoids the 15 MB GIF cap — Twitter's MP4 cap is much higher.
H.264 has a minimum-size overhead from the container, headers, and keyframes. For GIFs under ~50 KB, the MP4 may actually be larger or only marginally smaller. The format pays off above ~500 KB of GIF, and dramatically so above 2 MB. If you're optimising tiny GIFs, compress GIF directly may be the better option.