Every time someone posts a 12 MB GIF on Twitter and it loads as a slow, banded slideshow, the technically correct response is: that should have been an MP4. A GIF is a 1987 file format that stores animation as a sequence of full-frame indexed-color bitmaps capped at 256 colors per frame. An MP4 of the same animation, encoded with H.264 and yuv420p, is usually 10–20x smaller for visibly better quality. The web has known this for a decade. Twitter has known this so well that when you upload a .gif file, it silently transcodes it to MP4 on the server and serves you back a video. Discord does the same. Slack does the same.

The catch is that not every platform does that conversion for you, and not every workflow wants to wait for it. If you are pasting an animation into a Notion page, embedding it into Google Slides, attaching it to a Linear ticket, or feeding it into a video editor, MP4 is what you actually want. And the easiest way to get there is in a browser tab without uploading the file to anyone's server. This guide walks through the fast path, the math behind why MP4 wins, and an honest head-to-head against the usual suspects.

TL;DR

  • Use Clipy's GIF to MP4 converter. Drop the file in, wait a few seconds, download the MP4. The conversion runs in your browser tab — your file is never uploaded.
  • Output is H.264 video in an MP4 container with yuv420p pixel format, which means it will autoplay correctly on every browser, social platform, and embed surface that exists.
  • For a typical 5 MB GIF you should expect an MP4 in the 200–800 KB range with no visible quality loss. Sometimes much smaller.
  • If you ever need to go the other way — MP4 back to GIF for a Slack reaction or an old-school forum — use MP4 to GIF. If you need to shrink a GIF without converting it, Compress GIF does it.
  • FFmpeg one-liner if you prefer command line: ffmpeg -i in.gif -movflags +faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" out.mp4

Why GIF loses the size fight by orders of magnitude

A GIF stores every frame as its own image. There is some intra-frame compression — LZW, the same algorithm that powers TIFF — and there is a crude form of inter-frame compression in the form of frame disposal flags that let you only transmit the rectangle of pixels that changed. That is the entire bag of tricks.

H.264, the video codec inside almost every MP4 you have ever seen, has thirty years of research on top of that. It predicts the next frame from the previous one, encodes only the residual difference, splits the frame into blocks that get motion vectors, runs an integer DCT on what's left, and quantizes the result against a perceptual model that knows the eye cares more about luminance than chroma. The 4:2:0 chroma subsampling in yuv420p alone throws away three quarters of the color information without you noticing, because human vision can't see it.

The other half of the math is the palette. A GIF is locked to 256 colors per frame. To make a smooth gradient or a realistic face look passable, the encoder has to dither — sprinkle pixels of nearby palette colors to fake the in-between shades — which is why GIFs of video footage always look like they were filmed through a screen door. MP4 keeps all 16.7 million colors. The smoothness comes for free.

None of this is news. What is news is that every modern browser, social platform, messaging app, and embed system understands MP4 better than it understands GIF. Twitter will give your MP4 inline autoplay. Twitter will silently re-encode your GIF and serve back exactly the MP4 you should have uploaded in the first place. You may as well skip the middleman.

Why CloudConvert lost the GIF-to-MP4 race

For about a decade, CloudConvert was the answer for any file format conversion you couldn't be bothered to do locally. The interface was clean, the format list was huge, and for GIF to MP4 specifically it just worked. In 2026, it loses on a few fronts.

The free tier caps conversions per day and the file size for free conversions is small. Paid plans start above zero. The conversion is server-side, which means your file has to upload, wait in a queue, transcode, and download back to you. For a 50 MB GIF on a home connection that round trip is genuinely slow. Worst of all, the file leaves your machine and lives on someone else's servers for some retention window — that's a non-starter for screen recordings of internal dashboards, NDA'd product mockups, or anything sensitive.

Ezgif is the other classic. It is also server-side, and although it is free and fast for small files, it injects ads, has a 35 MB upload limit per file on the free tier for the GIF-to-video tool, and the conversion settings are exposed in a way that lets you make truly bad MP4 files by accident. The interface has barely changed in fifteen years, which is either charming or alarming depending on your taste.

Adobe Express requires an Adobe account. The conversion is server-side. The output quality is fine but the entire flow is gated behind signup, signin, and a soft push toward Creative Cloud. For a one-off GIF you got from Slack, that is too much overhead.

The browser-native approach skips all of that. Clipy's GIF to MP4 tool uses FFmpeg compiled to WebAssembly. The whole codec runs inside your browser tab. There is no upload, no queue, no account, no file size paywall, no retention window. The bytes never leave your machine.

The conversion settings that actually matter

If you've ever opened FFmpeg and been confronted with three hundred flags, here is the short list that determines whether your MP4 plays everywhere or breaks in weird places.

Codec: H.264 (libx264). H.265 is more efficient but Twitter, LinkedIn, Discord, and Slack inline preview all still prefer H.264 in 2026. AV1 is the future but support for casually-shared MP4s is still spotty.

Pixel format: yuv420p. This is the part everyone forgets. If you encode H.264 in yuv444p, QuickTime and most browsers play it, but Twitter and LinkedIn will silently fail to embed it. yuv420p has near-universal support. The -pix_fmt yuv420p flag is non-negotiable for anything you're going to share.

Even dimensions: H.264 in yuv420p requires the width and height to be divisible by 2. Many GIFs are odd dimensions because nobody enforced it at creation time. The scale=trunc(iw/2)*2:trunc(ih/2)*2 filter rounds both down to the nearest even number, which is invisible to the eye but makes the encoder happy.

Faststart: -movflags +faststart moves the MP4 metadata to the front of the file. Without it, a browser has to download the entire file before it can start playing because the moov atom lives at the end. With it, playback starts as soon as the first packet arrives. Essential for embeds and previews.

The Clipy converter sets all of these correctly by default. If you want to verify on the command line:

ffmpeg -i input.gif \
  -movflags +faststart \
  -pix_fmt yuv420p \
  -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" \
  -c:v libx264 -crf 23 \
  output.mp4

CRF 23 is the sweet spot for size vs quality on H.264. Lower is higher quality and larger file (CRF 18 is visually lossless to most viewers). Higher is smaller and worse-looking (CRF 28 is the floor before things start looking compressed).

What actually happens to your GIF when Twitter and Discord eat it

Knowing what the big platforms do under the hood explains why uploading an MP4 directly is always faster and higher quality than uploading a GIF and hoping for the best.

Twitter converts uploaded GIFs to MP4 (H.264 + AAC silent audio track) and serves them as inline-autoplay videos. The conversion is lossy because Twitter applies its own CRF and bitrate caps. If you upload your own well-encoded MP4 you get control of those parameters. If you upload a GIF, Twitter's defaults win.

Discord behaves the same way for GIFs over a certain size. Small inline GIFs (under about 8 MB) are served as-is. Larger ones are transcoded to MP4. Same loss-of-control situation.

Slack treats GIF and MP4 differently for inline preview. GIFs play inline if they're under the workspace's file size limits. MP4s play inline with a video control overlay. The MP4 is usually the better experience because users can pause, mute, scrub, and download.

The pattern: every modern platform secretly wants MP4. Giving it MP4 directly skips a transcode step, preserves your encoding choices, and produces a better playback experience for the viewer.

Size and quality expectations

A typical Slack reaction GIF that's 3–5 MB will convert to an MP4 in the 100–400 KB range. A 20 MB screen recording GIF will become a 1–3 MB MP4. A 100 MB GIF (yes, those exist — usually from people who recorded a screen with a GIF-output tool instead of an MP4-output tool) will compress to roughly 5–15 MB.

The ratio depends on three things: how repetitive the content is (a static slide animation compresses better than handheld video), what frame rate the GIF was captured at (60fps GIFs are wasteful and MP4 will exploit that), and the dimensions (lots of GIFs are 720p or 1080p and don't need to be).

If your output MP4 is still too large for whatever you're sharing it on, run it through the video compressor with a target size or a higher CRF. The compressor uses the same WebAssembly FFmpeg pipeline and runs in your browser tab. For a Discord 25 MB free-tier upload, target 20 MB and leave some headroom.

When you actually still want a GIF

There are real cases for keeping a GIF as a GIF in 2026. Email signatures still don't reliably autoplay MP4. Some old forum software, internal wikis, and bug trackers only embed images, not video. GitHub README files autoplay GIFs but require a click for video. Reddit chat reactions are still GIF-only in many interfaces.

For those, you want the smallest possible GIF, not an MP4. Use Compress GIF to shrink the palette, drop the framerate, or resize the file without changing the format. If you have an MP4 and need to ship a GIF to one of those legacy surfaces, MP4 to GIF does that conversion in the same browser-local way.

The checklist before you share

Before you paste that MP4 into a Twitter draft, a Slack message, or an embed in your docs, three sanity checks save embarrassment:

Does it autoplay muted? Open the MP4 in Chrome. If it autoplays silently, you're good. If it requires a click, the encoder probably wrote a non-yuv420p pixel format or skipped faststart. Re-encode.

Does the first frame look right? Some social platforms freeze on the first frame as a poster image. If your GIF starts with a blank or black frame, your MP4 will inherit that, and the inline preview will look broken. Trim the first frame off with the video cutter if needed.

Is it under the platform's size limit? Twitter is 512 MB for video uploads but compresses anything above ~50 MB heavily. Slack workspaces vary. Discord free tier is 25 MB, Nitro Basic is 50 MB, Nitro is 500 MB. Plan around the smallest of those if you don't know where the file will end up.

The fastest path, summary

Open Clipy's GIF to MP4 converter. Drop the file in. Wait a few seconds. Download. Done. The conversion is browser-local, the output is H.264 yuv420p with faststart enabled (correct settings for every platform that will eat it), and there's no upload, no account, no file size paywall.

If your input is unusually large or unusually long, the conversion takes longer in proportion. Your machine is doing the work, not someone else's server, so the speed scales with your CPU. On modern hardware, even a multi-minute screen recording GIF converts in a small handful of seconds.

For the inverse problem — when a platform actually still requires GIF — use MP4 to GIF. For compressing an existing GIF without changing format, Compress GIF. For shrinking the MP4 output further, video compressor. All of them run the same way: in your browser, no upload, no account.