The GIF format is just as popular as its ever been. It may even be more popular than ever before. People love sharing short, auto-playing clips on social media. and the GIF accidentally became the chosen format for that purpose. Unfortunately, the GIFs popularity doesn’t mean that the GIF is a good format.
While functional, the GIF format is archaic, providing minimal lossless compression via the LZW algorithm. JPEG, on the other hand, uses an image-specific compression method that takes advantage of quirks in human perception, reducing file size while retaining image quality. Worse still, GIFs are limited to a 256 color palette, (chosen from a 24-bit RGB field) which often leads to hideous dithering on anything complicated. Quality also varies dramatically based on the program used to render the GIF.
As far as conveying motion, the GIF standard essentially just sticks a bunch of still images together and then plays them one after another. While that might seem like a sensible way to show a short video clip, we’ve come a long way since those ancient days of 1989, the last time that the GIF standard was updated.
So, if GIFs are so terrible, what’s the better solution? Turns out that people have been thinking about this for a while, and we currently have several good answers.
MPEG-4 Video (.mp4)
Just a few years ago, a video wasn’t a viable replacement for autoplaying GIFs. Browsers required users to press a play button before the animation would begin, removing one of the greatest appeals for GIFs: ease of consumption. Today, however, all major browsers support autoplaying MPEG-4 video files without too much trouble. Most notably, MPEG-4 provides far better compression than GIF, often yielding files that are 20% the size of an analogous GIF. The best codec to use for this use case would be H.264. Eventually, H.265/HEVC will replace the H.264 codec, but for now, the newer codec has hardly any browser support.
WebM’s support is not as widespread as video or GIF., but it still includes almost all the major browsers. The only notable absences are iOS Safari and Internet Explorer, but both browsers can support .webm videos with an installed codec pack. If you’re playing videos within an app, you can include the codec within the application, ensuring clean processing.
Depending on what you’re playing back, you might be able to squeak by with CSS animations. With a little practice, you can create complex animation using hand-drawn and downloaded assets. For example, if you had a spinning logo GIF that you wanted to replace, that could be replaced with CSS animations easily enough.
Matroska (.mkv) is a niche video container that might replace MP4 one day. It’s open-source and more flexible than MP4, providing support for just about any codec and including options for things like in-file subtitles and multiple audio tracks. You’ll want to test to make sure your target browsers support .mkv playback before you go all-in, however. Also, Matroska is not supported by the HTML <video> element, requiring a separate player construct to make it work.
Converting to MP4
MP4 is the clear winner in the round-up. It has the best support across browsers, it compressed effectively, and uses fewer system resources during playback. The next step is actually making an MP4. You can export from a video app to MP4 or, more likely, convert an existing GIF to an MP4 file.
To convert from GIFs to MP4, you can use ffmpeg in the command line. For example, the following command would convert a GIF into an MP4 video without any additional options:
ffmpeg -i input.gif output.mp4
Fortunately, ffmpeg is broadly configurable, providing far more options than we see here. Check out the Google’s developer guide to ffmpeg for the best explanation of the various features.
Setting Up Autoplay
Getting autoplay working within the browser is dead simple. You’ll be using the <video> element to support playback of motion clips, which is universally supported as part of HTML5. Add the autoplay attribute, and you’ll be in business. The video will autoplay as soon as it’s loaded:
<video autoplay loop muted playsinline> <source src="movie.webm" type="video/webm"> <source src="movie.mp4" type="video/mp4"> <source src="movie.ogg" type="video/ogg"> Your browser does not support the video tag. </video>
The video element also provides for graceful degradation through multiple video formats. The videos will be loaded in the order listed, falling back on the next video down the line as you go until a video is supported by the client browser.
Let’s look at the attributes in your opening video tag. First, we have autoplay, as mentioned above. Predictably, the loop attribute plays the content from the beginning after the video reaches the end. Muted silences any audio tracks, and playsinline supports inline video play. Importantly, the muted attribute is mandatory for autoplay functionality and playsinline in necessary for autoplay on iOS.
Also, note the absence of the controls attribute in the opening video tag. This reproduces the experience of GIFs, which don’t typically have playback controls of any kind. With the use of the <track> attribute (explained here), you can set subtitles and captions alongside your video.
If you’re looking to replace GIFs on your website, you can use a policy of graceful degradation. Using this policy, you can try with the best format first. If the browser doesn’t support that format, you can fall back to another and another. In this case, you could start off with .webm, which provides great compression and quick client-side processing. After that, you can fall back on the MP4, which is supported by basically everyone. And if an MP4 won’t play, you can finally fall back on a GIF within an <img> tag.
You might also be interested in the following posts: