Animated WebP in Email: Which Clients Render It

Why email is a special case

On the web you can reach for <video>, CSS animations, or JavaScript-driven transitions. In email, none of those exist. The inbox is a stripped-down document environment: no JavaScript, no CSS keyframes in most clients, no <video> tag with a fallback poster. The only animation primitive that survives across a broad range of clients is an <img> tag pointing to a file the client itself knows how to decode frame by frame.

Historically that meant GIF — a format from 1989 with an 8-bit color palette and no inter-frame compression. Animated WebP is a modern alternative with full color and much smaller files, but its support in email is patchy and varies by client, platform, and sometimes by email account type within the same app.

Some clients also strip background-image animations outright, so CSS background tricks that work in a browser will not work here at all. This guide focuses on <img>-delivered animated WebP, which is the only delivery method with any realistic reach in email today.

The render matrix: client by WebP support

The table below reflects known behavior as of May 2026, cross-referenced against Can I Email — image/webp and supplemental Litmus testing notes. Static WebP support does not imply animated WebP support — those are separate decoder paths. Where I could not confirm animated behavior independently, I have marked the cell as unknown and linked to the source.

Source: Can I Email — image/webp (checked May 2026). Animated-WebP-specific behavior supplemented from Litmus test notes and independent verification. Entries marked "unknown" could not be confirmed independently.

Where animated WebP renders, where it falls back to first frame

The clients with reliable animated WebP support all share one trait: they use a real browser engine (WebKit, Blink, or Gecko) to render email. Apple Mail on macOS and iOS, Gmail in Chrome, Outlook.com, Proton Mail, and Thunderbird all fall into this category. If the rendering engine can play animated WebP in a browser tab, it will generally play it in the inbox too.

Outlook on Windows is the well-known exception, and it is a significant one because it still commands a large share of enterprise email opens. The problem is not WebP specifically — Outlook 2016 and 2019 on Windows famously strip GIF animation as well, reducing animated GIFs to their first frame. Both formats share the same fate: a static image where the sender intended motion. This is a consequence of Microsoft routing email rendering through Word's layout engine rather than a browser engine, a decision that has persisted through multiple Outlook versions.

Yahoo Mail is more complicated. Their sanitizer behavior is inconsistent enough that I would not rely on animated WebP playing there. If your list has significant Yahoo volume, design the first frame to stand alone as a complete message — animation should be an enhancement, not the message itself.

The practical rule: if more than 15–20% of your audience is on Outlook for Windows, the animation will be invisible to a meaningful portion of your list. Design defensively: make the first frame informative, and treat animation as progressive enhancement.

The MJML pattern with a fallback GIF

MJML is the most common template layer for production HTML email. It compiles to table-based HTML and handles many cross-client quirks automatically. The main limitation relevant here: MJML does not support <picture> natively. The mj-image component generates a plain <img> tag, which is exactly what you want for maximum compatibility.

If you need a GIF fallback specifically for Outlook on Windows, you can use MSO conditional comments inside an mj-raw block. The pattern below shows both approaches: a simple mj-image pointing to a WebP (which works for all browser-rendered clients) and an MSO conditional that swaps in a GIF only for the Word-engine Outlook variants.

<mjml>
  <mj-body>
    <mj-section>
      <mj-column>

        <!--[if mso]>
        <mj-raw>
          <img
            src="https://example.com/hero-fallback.gif"
            width="600"
            alt="Summer sale — 30% off this week"
            style="display:block;max-width:600px;width:100%;"
          />
        </mj-raw>
        <![endif]-->

        <!--[if !mso]><!-->
        <mj-image
          src="https://example.com/hero.webp"
          width="600px"
          alt="Summer sale — 30% off this week"
        />
        <!--<![endif]-->

      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

In practice, many teams skip the conditional entirely and just ship the GIF. The logic: if you need to maintain two assets (a WebP and a GIF fallback), you now have a versioning and caching problem. For a one-off campaign, the extra complexity is rarely worth it. The GIF will be larger — sometimes significantly — but it works everywhere without conditional branching.

The simplest production pattern is: ship a GIF, accept the file size, keep your template simple. If your animation is under 150 KB as a GIF, start there. Reach for the WebP-with-fallback pattern only when file size genuinely matters — for example, when you are approaching Gmail's clipping threshold.

The <picture> source-set in email (which clients honor it)

The <picture> element with a <source type="image/webp"> and an <img> GIF fallback is a clean solution in a browser. In email, the support picture is incomplete:

• Apple Mail renders <picture> correctly and picks the WebP source.
• Gmail strips the <source> elements but preserves the <img> fallback — so GIF displays, not WebP. The pattern degrades gracefully.
• Outlook on Windows strips both <source> and may also mangle the <img>, depending on version. You still need the MSO conditional approach for reliable Outlook fallback.

If Apple Mail is a meaningful segment of your audience, the <picture> pattern lets those users see the smaller animated WebP while everyone else gets the GIF:

<!--[if mso]>
<img
  src="https://example.com/hero-fallback.gif"
  width="600"
  alt="Summer sale — 30% off this week"
  style="display:block;max-width:600px;width:100%;"
/>
<![endif]-->

<!--[if !mso]><!-->
<picture>
  <source
    type="image/webp"
    srcset="https://example.com/hero.webp"
  />
  <img
    src="https://example.com/hero-fallback.gif"
    width="600"
    alt="Summer sale — 30% off this week"
    style="display:block;max-width:600px;width:100%;"
  />
</picture>
<!--<![endif]-->

This is raw HTML rather than MJML markup — you would drop it into an mj-raw block if you are using MJML. It requires you to maintain both a .webp and a .gif asset, so weigh the complexity against the file-size benefit for your specific audience split.

File-size ceilings in major clients

Each major client enforces its own limits, and violating them produces different failure modes:

• Gmail clips the entire email body at roughly 102 KB of HTML. This is the HTML source size, not the image file size — but Gmail also does not load images until the user explicitly allows it, so image bytes do not count toward the clip. The practical concern is keeping your template HTML lean.
• Outlook on Windows has historically had a ~700 KB per-image ceiling for embedded images in certain contexts. For externally hosted images (a URL in the src attribute), this limit is less relevant — the image is fetched at display time.
• Apple Mail is much more permissive. Large animated WebP files (several MB) will load, though slowly on cellular connections.

The practical design target for an animated image in email is under 150 KB. That number is not an official platform limit — it is a reasonable ceiling that keeps load times fast on mobile connections, stays well below any client threshold, and gives you headroom for other assets in the email (logos, product shots, CTAs).

For animated WebP specifically: use quality 65, limit frame rate to 10 fps, and cap width at 480 px for a typical email column. Those settings are the same ones in the optimal settings guide email preset. A 3-second animation at those settings should land well under 100 KB in most cases. These numbers were last verified in May 2026; client thresholds do change.

Pre-flight checklist before sending

Before deploying an animated WebP (or animated GIF) to a real list, work through this checklist:

• Test in Litmus or Email on Acid. Run your template against the client matrix before sending. These tools render your email in real clients and flag broken images, layout shifts, and missing fallbacks. One Litmus test is cheaper than re-sending to a burned list.
• Always ship a fallback. Whether you use the <picture> pattern, MSO conditional comments, or just a plain GIF, never assume the animated WebP will render for everyone. Design the first frame to communicate the message without motion.
• Stay under 150 KB for the animated asset. If your WebP or GIF is larger, reduce frame rate first (drop from 15 fps to 10), then quality (try 65), then dimensions (480 px width is usually enough for an email column).
• Strip metadata. Run cwebp with metadata stripping enabled, or post-process with a tool that strips XMP and EXIF. Metadata adds bytes and provides no value to email recipients.
• Write meaningful alt text.Many clients show images as blocked by default and display alt text while loading. Alt text like "animated banner" is useless. Write something that conveys the offer — for example, "Summer sale — 30% off through Sunday."
• Check your list's client distribution. If 40% of your opens come from Outlook on Windows, animation will be invisible to nearly half your audience. Know this before you spend time optimizing the WebP.

What replacing an animated GIF with animated WebP actually does

I do not have A/B test data comparing animated WebP against animated GIF in email — the browser-rendered share of most lists is large enough that both formats will generally display, making it difficult to isolate format as the independent variable. What I can describe is the mechanical impact.

A typical animated GIF hero — a 5-second, 600 px wide product clip at 15 fps — often lands around 1.2 to 1.8 MB. Converting the same source to animated WebP at quality 65 and 10 fps typically produces a file in the 200 to 300 KB range. That is a 5–7x reduction. The practical consequence: your email loads faster on cellular connections, the asset is well under any reasonable client file-size ceiling, and you have significant headroom left in your total email payload for other assets.

For Gmail specifically, moving from a 1.6 MB GIF to a 250 KB WebP does not affect the 102 KB HTML clipping threshold (images are hosted externally and fetched on display, not embedded in the HTML body). But it does affect how quickly the image appears after the email opens, which matters on mobile.

If you are currently sending emails with large animated GIFs, converting to animated WebP for the clients that support it is worth doing — not because of any measurable conversion lift, but because smaller files are faster, cheaper to serve, and better for your subscribers on limited connections. Use the email use-case page for a quick converter setup, or read the optimal settings guide for the full encoding parameter reference.