The GIF You See on Twitter Is Actually an MP4. Most Platforms Converted It Already.
When you upload an animated GIF to Twitter, you are uploading a file that Twitter immediately discards. The platform accepts the upload, converts the GIF to a silent MP4 video, and serves the MP4 to everyone who sees the post. The animation looks the same. The looping behavior is identical. The file format is completely different.
This quiet conversion happens on nearly every major platform that appears to serve GIFs. Tumblr introduced its GIFV format to do exactly this, transparently converting uploaded GIFs to more efficient video formats for delivery. Discord, Slack, and several messaging services perform similar transcoding. The reason is always the same: a GIF and an MP4 can display identical visual content, but the MP4 is typically five to twenty times smaller, sometimes far more.
Understanding why requires a brief look at where the GIF format came from and what constraints it was designed to operate under, because those constraints have been obsolete for decades, and platforms have been quietly working around them ever since.
Where GIF Came From and Why It Was Always Inefficient
Steve Wilhite was a software engineer at CompuServe in 1987. His assignment was to create an image format that would look good and download fast over the dial-up modem connections of the era, where 2,400 bits per second was considered respectable. The format he developed, GIF, debuted on June 15, 1987. It used a compression algorithm called LZW, which Wilhite had found described in a technical journal, combined with a palette of up to 256 colors per frame.
That 256-color ceiling was not an oversight. It was a deliberate tradeoff made for the constraints of 1987 hardware and network speeds. Storing more color information per pixel would have increased file size, and increasing file size would have made GIF impractical on the connections it was designed for. The limitation was rational given the technology of the time.
Animation was added in GIF89a, published in 1989. The format could store multiple image frames with timing information, and playback loops were specified by an extension that became the de facto standard for looping animations. GIF animation works like a flip book: it stores each frame as a complete indexed image. There is no concept of what changed between one frame and the next. Frame 1 is a full image. Frame 2 is a full image. Every frame is complete and independent.
By the early 1990s, GIF had become a patent dispute. Unisys held a patent on the LZW compression algorithm and entered into licensing negotiations with CompuServe in 1993, announcing an agreement on December 24, 1994. The dispute accelerated interest in alternative formats, ultimately contributing to the development of PNG. But GIF survived, and GIF animation survived, precisely because no equivalent animated image format emerged to replace it for the open web. The LZW patents expired around 2003, removing the licensing concern, but by then the format was so embedded in web culture that it continued to dominate animated image use for another decade.
Why MP4 Is So Much Smaller for the Same Content
MP4 is a container format that uses temporal compression, the fundamental technique that GIF lacks entirely. Instead of storing each frame as a complete image, a video codec like H.264, which is the encoding most commonly used inside MP4 files, stores a reference frame and then records only the differences between subsequent frames. For a looping animation where most of the image stays static and only a portion moves, this is an enormous efficiency gain.
Consider a simple example: an animated GIF showing a bouncing logo against a white background. Every frame stores the entire image, including the white background, even though the background never changes. In an MP4 of the same animation, the background is stored once in the reference frame and then ignored in all subsequent frames. Only the pixels where the logo moves are recorded. The result is a dramatically smaller file.
The gap in practice is consistent and large. Google's Web Fundamentals documentation gave a concrete benchmark: a 3.7 megabyte GIF encoding of a particular animation became a 551 kilobyte MP4 with equivalent visual quality, an 85 percent reduction. Twitter reports that its MP4 conversions of uploaded GIFs run approximately 10 times smaller than the original files. Tumblr's engineering team, which has published detailed notes on its transcoding pipeline, found similar reductions and noted that their MP4 conversion produces faster loading times and lower data consumption in almost every circumstance with no discernible quality loss.
The one technical disadvantage of MP4 relative to GIF is transparency support. GIF supports transparent pixels natively. Standard H.264 encoded MP4 does not. Tumblr's conversion system specifically checks the first frame for transparency before deciding whether to convert; GIFs that rely on transparency are served in their original format or as animated WebP instead. For most animated GIFs used on social media, this is not a concern, because the vast majority are opaque.
Conclusion
Most consumer-facing platforms handle the conversion silently. If your goal is to share an animation on Twitter, you can upload the GIF and let Twitter transcode it. The viewer never knows the difference.
The cases where you need to convert manually are distribution channels that do not perform server-side transcoding. Ad platforms are the most consistent example. Facebook and Instagram do not accept GIF files for video ad placements. Twitter's native ad platform has stricter file size limits for GIF than for MP4, and most campaigns will hit those limits before reaching adequate length or quality. Google's display advertising network does not support GIF. In all these cases, converting the animation from GIF to MP4 before upload is required, not optional.
Web performance is a second case. If you are embedding an animation directly in a web page as an image element, you are serving the GIF file directly to the visitor. No server-side transcoding occurs. A 3 megabyte GIF will transfer as 3 megabytes. Google's performance guidelines have explicitly recommended replacing GIF with video elements for on-page animations precisely because the file size difference is large enough to affect page load times and Core Web Vitals scores.
Email is the notable exception. Most email clients do not render HTML5 video elements. The video tag that makes an MP4 loop silently in a browser simply does not work in Gmail, Outlook, or Apple Mail for most users. For animated content in email newsletters, GIF remains the only format that plays reliably. Converting to MP4 for email delivery would produce a static image in most clients, which defeats the purpose of the animation entirely.
The practical rule: if you are going anywhere that has a server-side transcoding pipeline, upload the GIF and let the platform handle it. If you are going anywhere that serves your file directly to users, whether a web page, an ad network, or a platform that does not transcode, convert to MP4 first. A GIF to MP4 converter processes the conversion in the browser and produces a download-ready file sized appropriately for wherever it needs to go.
Frequently Asked Questions
Why is MP4 so much smaller than GIF for the same content?
MP4 uses temporal compression, storing only what changes between frames. GIF stores each frame as a complete image. For looping animations with repeated or similar frames, this difference produces massive file size advantages for MP4.
When should you keep a file as GIF instead of converting to MP4?
Email is the main exception. Most email clients do not support video tags, so GIF is the only animated format that works in HTML email. Outside email, MP4 is almost always preferable for file size.
Do ad platforms accept GIF files?
Most major ad platforms do not. Facebook, Instagram, and Google display networks require video formats. GIF animations intended for ads typically need to be converted to MP4 before upload.