Video in email marketing: the GIF workaround that actually ships

The inbox does not play video, and the numbers say why#

Marketers keep asking how to drop a playable demo into a marketing email, and the honest answer is that you mostly cannot. The HTML5 <video> element, the same tag that autoplays a hero loop on a landing page, is supported in roughly a quarter of email clients: Can I Email puts it at 24.39% (19.51% full, 4.88% partial) across the clients it tests¹. Apple Mail on macOS and iOS renders it, but only from version 13.3, only when you supply a controls attribute, and never on autoplay. Gmail does not render it at all: it rewrites <video>, <source>, and <track> into empty <u></u> tags. Outlook on Windows strips the tag, and so do Yahoo and AOL. Even where the element survives, a strict Content Security Policy in Outlook.com and ProtonMail blocks the file from loading. Mailchimp says the same thing from the sending side: "Most email clients can't display embedded video content, and will strip the code from your email"⁵.

So the working pattern is not a video. It is a picture that looks like a video, wired to a link that opens the real thing on a page you control. That picture is either an animated GIF or a static thumbnail, and the whole craft of video in email is choosing between those two and getting the details right. This is the email cell of the one-recording, every-channel matrix, taken down to the mechanics.

What each email client does with an animated GIF#

An animated GIF is the closest thing to motion that the inbox supports broadly. Can I Email records GIF rendering at effectively total coverage, so a looping clip reaches almost every reader. The exception is the one that always ruins email plans: Outlook on the Windows desktop (2007 through 2019) "Does not support animated gif images," rendering a single static frame instead². Newer Outlook 2019 on an Office 365 account is oddly specific: it plays the loop three times, stops, and shows a play button to replay it.

The obvious optimization is to reach for the format a README would use. An animated WebP is several times smaller than a GIF for the same motion, so why not send that instead? Because WebP animation is dead in the inbox. Can I Email shows Gmail "Converts file to jpg" and "Does not support animation," and Apple Mail renders no WebP at all³. The GIF is wasteful, but it is the only motion format the clients agree on. The two-pass palette encoding that keeps a GIF small and clean is the same work you would do for a repository; email just spends the result on a stricter budget.

The first frame has to carry the whole message#

Two facts collapse into one design rule. First, Outlook on the desktop freezes a GIF on a single static frame, in practice the first one, so a real slice of your list sees a still and never the loop. Second, plenty of clients block remote images until the reader clicks to display them, and a heavy GIF paints progressively, so the first thing anyone sees is either the opening frame or a broken-image box. The rule that falls out of both: whatever renders first has to state the value on its own. Show the product mid-task with a short label, not a fade-in from black and not a spinner. Treat the animation as a bonus for readers whose client cooperates, and the first frame as the message every reader gets. It is the poster-frame discipline of a video thumbnail applied to a format that, for a chunk of your audience, will never move at all.

The GIF weight budget email actually enforces#

A GitHub README has a hard ceiling: 10 MB per image. Email's budget is softer and stricter at the same time. An email image loads over whatever connection the reader happens to be on, often a phone on cellular data; it competes with a full inbox for a few seconds of attention; and a GIF that must buffer before it loops will not have looped by the time the reader has scrolled past. The target most senders settle on is well under a megabyte, frequently a few hundred kilobytes, which is a demanding ask for motion given how badly GIF compresses a moving frame.

The levers are the familiar ones, in the same order of impact: width first, then framerate, then length, then color count. Email just pushes each one harder. A continuous scroll is the worst case, because every pixel changes every frame; a click-through demo that holds still between three deliberate actions compresses far better, because the encoder can skip the unchanged regions. So the GIF that actually fits an email is usually the one that shows a few settled states rather than a pan. Keeping it short pays a second dividend: a GIF cannot be paused, and motion that autoplays past a few seconds trips a Level A accessibility rule, so a tight three-second loop is both the lighter file and the more considerate one.

The faux-video hover trick, and why it stays a demo#

There is a clever technique that gets closer to real playback, and it is worth understanding precisely so you know when not to use it. Litmus calls it faux video: layer a static cover image with a play button over an animated GIF of identical dimensions, then use a CSS opacity transition so that hovering the cover fades it out over about 0.3 seconds and reveals the animation beneath⁴. It works in Gmail, the Gmail app, Apple Mail, iOS Mail, Samsung Mail, and Outlook for Mac. It fails in AOL, Yahoo, and Outlook.com, which do not support CSS opacity, so the cover never lifts and the reader is stuck on the static image.

The client gaps are the small problem. The real one is a contradiction Litmus flags in its own writeup: on mobile, "if a clickthrough is applied in your email, the link will launch the browser on tap and the subscriber will never see the video." Read that twice. Faux video is built to make people watch inside the inbox, but the conversion event for a product demo is the click out to a page where the viewer can sign up. Wire the trick for the inbox reveal and you forfeit the click; wire it for the click and the hover animation never fires, because a phone tap cannot both hover and follow a link. That is why faux video is a fine portfolio piece and rarely what a revenue-driven campaign ships.

The pattern that ships: a thumbnail wired to a hosted page#

The approach that survives every client on the list is the least clever one: a single image with a visible play button, linked to a hosted video page. Mailchimp's built-in video block does exactly this, generating a thumbnail of a player so that "when a recipient clicks the thumbnail, they can watch the video in a new browser window"⁵. It renders the same in Gmail, in Apple Mail, and in frozen-GIF Outlook, because underneath it is only an <img> inside an <a>. Make that image a lightly animated GIF if you want a hint of movement for the clients that animate, but design it so the static first frame is the entire pitch and the link is the point.

That link is where the demo actually lives, so the page it opens has to load the video fast and clean. It is also the only version of video in email you can measure honestly: an embedded loop gives you an open at best, while a wrapped thumbnail gives you a click, which is the number this channel is graded on. One last reason to keep the inbox asset and the hosted asset separate is that they can still share a source. If the demo is generated from a committed storyboard, one recording produces both the hosted MP4 and the email GIF as two renders rather than two shoots, the same discipline behind a README loop that recaptures itself when the product changes. Our own engine, aidemo, can spit out an email-sized GIF and a full-length hosted clip from one such spec; its honest limits are that it captures browsers only, the spec is written by a coding agent rather than assembled in a timeline editor, and it ships no click-to-edit UI, so it fits a demo you keep in step with the product rather than a one-off. Whatever tool you reach for, the shape holds: cut the email GIF and the hosted video from one master, let the first frame do the work, and let the click carry the reader to where a video can finally play.

Sources#

1. Can I Email — HTML5 video element support in email clients
2. Can I Email — Animated GIF image support in email clients
3. Can I Email — WebP image support in email clients
4. Litmus — Faux Video: A Fallback for Video in Email
5. Mailchimp — Add a video to a campaign (thumbnail links to hosted video)

FAQ#

Can you embed a playable video in an email?#

Rarely, and not reliably. The HTML5 <video> element works in only about a quarter of email clients per Can I Email: Apple Mail plays it with a tap, but Gmail rewrites the tag to nothing, Outlook on Windows strips it, and Outlook.com and ProtonMail block the file with a Content Security Policy. Because you cannot predict which client opens your message, the shipping pattern is an image, animated GIF or static thumbnail, that links to a hosted page where the video actually plays.

Why does my email GIF show only the first frame in Outlook?#

Outlook on the Windows desktop (2007 through 2019) does not animate GIFs, so it renders a single static frame instead of the loop. Outlook 2019 on an Office 365 account plays the animation three times and then stops. There is no markup fix, so design the GIF so its first frame states the whole message on its own, and treat the motion as a bonus for the clients that support it.

What size should a GIF be for an email?#

Aim well under a megabyte, often a few hundred kilobytes, because email images load over cellular connections and compete for a few seconds of attention before the reader moves on. GIF compresses motion poorly, so cut width first, then framerate, then length. A click-through demo that holds still between a few deliberate steps fits far more easily than a continuous scroll, which changes every pixel of every frame.