WebP in Emails: Client Support, Fallback Strategies, and Best Practices

The WebP Promise and the Email Problem

WebP delivers genuinely impressive compression. A product photo that weighs 180 KB as a JPG can drop to 120 KB as WebP at equivalent quality. A PNG with transparency that clocks in at 95 KB might shrink to 65 KB in WebP format. For websites, this is a straightforward win — browser support has been universal since 2022, and serving WebP via <picture> or CDN content negotiation is standard practice.

Email is a different story. The email rendering environment is one of the most fragmented in computing. A single HTML email gets parsed by Outlook 2016 on Windows (which uses Microsoft Word's rendering engine), Apple Mail on iOS (WebKit-based), Gmail on Android (embedded WebView), and Yahoo Mail on the web — all in the same send, and all with different capabilities. What works beautifully in one client produces a broken image icon in another.

Before you adopt WebP for email campaigns, you need to understand exactly where it works, where it fails, and what your fallback strategy should be.

WebP Email Client Support in 2026

The support landscape is fractured enough to require a detailed breakdown by platform. The same email client behaves differently depending on the operating system it runs on.

The critical gap is Outlook on Windows, which serves a significant portion of enterprise email recipients. Outlook 2016, 2019, 2021, and the Microsoft 365 desktop app all use Microsoft Word's rendering engine for HTML email, not a browser engine. Word has no WebP support. When an Outlook Windows user receives an email with an unguarded WebP <img> tag, they see a broken image icon — not a degraded image, a completely missing one.

Why Gmail's "Partial" Support Matters

Gmail deserves special attention because it is the largest email provider by user count, and its WebP behavior is counterintuitive.

When a Gmail user opens an email in Chrome on the web, WebP images render — Google's own browser handles the decoding. But Gmail processes images through its image proxy server before delivering them to the client. This proxy rewrites image URLs to cache them through Google's CDN, which can affect transparency handling.

More significantly, Gmail's mobile apps (Android and iOS) behave differently from the web client. They use embedded WebViews that may not consistently decode WebP, and older versions of these apps running on older OS versions can fail entirely. Gmail also strips or ignores <picture> elements in many contexts — the entire tag is removed, leaving no image at all rather than falling back to the <img> inside it.

This is the fundamental problem with the <picture> approach in email.

The <picture> Element: Why It Fails in Email

On the web, the <picture> element is the standard way to provide WebP with a JPG or PNG fallback:

<picture>
  <source type="image/webp" srcset="hero.webp" />
  <img src="hero.jpg" alt="Product hero image" width="600" />
</picture>

Browsers that support WebP load hero.webp; those that do not skip the <source> element and load hero.jpg from the <img> tag. Elegant, standards-compliant, and completely reliable in browsers.

In email clients, this breaks down in multiple ways:

1. Outlook on Windows ignores <picture> entirely and tries to render whatever <img> it finds — which in this case is the JPG fallback. This part works, but only because Outlook ignores the whole <picture> construct.

2. Gmail strips <picture> and <source> tags from the email HTML before rendering. When Gmail encounters <picture>, it removes it along with the contained <source> elements. The <img> inside may or may not survive this stripping, depending on Gmail version and platform.

3. Some older webmail clients treat <picture> as an unknown element, ignore the <source>, and attempt to load the <img> fallback — which is the correct behavior, but it happens by accident rather than design.

The net result is that <picture> is not a reliable WebP fallback mechanism for email. You need a different approach for the clients that actually need it.

MSO Conditional Comments for Outlook Fallback

Microsoft Outlook on Windows has supported conditional comments since the early days of HTML email. These are HTML comments that only Outlook's rendering engine parses:

<!--[if !mso]><!-->
<img src="image.webp" alt="Product image" width="600" style="display: block; max-width: 100%;" />
<!--<![endif]-->
<!--[if mso]>
<img src="image.jpg" alt="Product image" width="600" style="display: block; max-width: 100%;" />
<![endif]-->

In this pattern:

• The <!--[if !mso]><!--> block is visible to all clients except Outlook on Windows
• The <!--[if mso]> block is visible only to Outlook on Windows

This gives Outlook recipients a reliable JPG, while all other clients receive the WebP. The two images are separate <img> tags — no <picture> element involved — which avoids Gmail's tag-stripping behavior.

The limitation is that this only solves Outlook. Gmail's partial WebP support and transparency handling issues remain unaddressed for users who open Gmail in non-Chrome browsers or on mobile apps.

The CDN Content Negotiation Approach

The most robust solution bypasses HTML fallback logic entirely. Instead of including different <img> tags for different clients, you serve a single URL that returns the optimal format based on the requesting client's capabilities.

CDNs like Cloudflare Images, imgix, Cloudinary, and AWS CloudFront with Lambda@Edge can inspect the Accept request header and serve WebP to clients that declare image/webp support, and JPG or PNG to those that do not:

Accept: image/avif,image/webp,image/apng,image/*

Your email template references a single URL:

<img src="https://cdn.example.com/hero.jpg" alt="Product" width="600" />

But the CDN serves hero.webp to capable clients and hero.jpg to others — transparently, without any conditional logic in the email template. This works because email clients send standard HTTP requests to load remote images, and those requests include the Accept header.

The trade-off is that this requires CDN infrastructure and that images must be loaded remotely (not embedded). For email campaigns, remote image loading is already standard practice, so this is rarely a barrier.

WebP File Size Comparison for Email

WebP's compression advantage is real and measurable. For email, where every kilobyte affects load time and deliverability, the savings add up.

Across photographic content, WebP is typically 25-34% smaller than JPG and 35-60% smaller than PNG at equivalent quality. For emails with multiple images, this can reduce total image payload by 25-35% — meaningful for recipients on mobile data and for getting under Gmail's 102 KB HTML clip threshold.

If you need to convert existing JPG or PNG assets to WebP, the WebP converter handles batch conversion with quality control. For the reverse — converting WebP assets to JPG for fallback production — use the JPG converter.

Transparency in Email: A Specific Problem

PNG's alpha channel transparency is one of its key advantages over JPG for logos and UI elements. WebP also supports transparency, but email client handling of WebP transparency is inconsistent even where WebP itself is supported.

Gmail's image proxy sometimes flattens WebP transparency to white when processing images. The result is a logo that looks correct in Gmail Chrome but has a white box behind it in Gmail Android. This affects branded elements like logos, watermarks, and product cutouts.

For transparent images in email:

• Safest: Use PNG for transparent elements; WebP for opaque photographs
• Conditional: Use WebP for transparent elements only where you control the client (transactional emails to known app users, for example)
• CDN route: Use a CDN that correctly preserves WebP transparency and test behavior across clients

The image converter hub supports converting between PNG, WebP, and other formats while preserving transparency settings.

Recommended Strategy by Email Type

Not all emails carry the same risk from client incompatibility. The right WebP approach depends on what you are sending.

Transactional Emails (receipts, confirmations, alerts)

These go to known users with predictable clients. If your user base is heavily iOS (Apple Mail) or tech-forward, WebP is safer. For enterprise SaaS with corporate users on Outlook, default to JPG/PNG.

Recommendation: JPG/PNG unless you have client data showing low Outlook-on-Windows usage.

Marketing Campaigns (newsletters, promotions)

B2C email lists skew toward Gmail and Apple Mail, where WebP support is partial to good. But a campaign to 50,000 subscribers likely includes thousands of Outlook Windows users.

Recommendation: CDN content negotiation for maximum compatibility, or MSO conditional comments if you control image hosting.

Transactional Marketing (cart abandonment, re-engagement)

High deliverability risk means keeping email size lean. WebP's file size advantage is genuinely valuable here.

Recommendation: CDN content negotiation. The investment pays off in faster load times and reduced HTML size.

Internal Newsletters (corporate HR, company announcements)

Corporate environments typically mean a high concentration of Outlook on Windows.

Recommendation: JPG/PNG. Do not risk broken images for your CEO's all-hands email.

Building a Test Workflow

Whatever fallback strategy you choose, testing is mandatory. The gap between what you design and what recipients see is wide enough to require empirical verification.

Tools like Litmus and Email on Acid render previews across 90+ client combinations, including multiple versions of Outlook on Windows and various Gmail configurations. Run your WebP emails through a rendering preview before any significant send.

For a quick local test:

1. Open your email HTML in Chrome — tests modern browser WebP support
2. Open it in a text-based browser like Lynx — tests alt text fallback
3. Send a test to an actual Outlook 365 desktop account — tests the most common problem client
4. Send to a Gmail account and open on iOS — tests Gmail mobile behavior

Compare the image converter output against your test results. If a WebP image fails in any required client, you have your answer on format choice.

Frequently Asked Questions

Does Gmail support WebP images?

Gmail on the web in Chrome renders WebP images inline, but the behavior is inconsistent across platforms. Gmail's mobile apps and non-Chrome browsers have partial support that varies by version and OS. Gmail also strips <picture> elements, making CSS fallbacks unreliable. The safest approach for Gmail-heavy lists is CDN-based format negotiation or sticking with JPG/PNG.

Will WebP images break in Outlook?

Outlook on Windows — including Outlook 2016, 2019, 2021, and the Microsoft 365 desktop app — does not support WebP. An unguarded <img src="image.webp"> tag renders as a broken image icon. Outlook on Mac and Outlook Web Access (OWA) use WebKit and render WebP correctly. Use MSO conditional comments to provide JPG fallbacks specifically for Outlook on Windows.

Can I use the <picture> element in HTML email?

Technically, yes, but with significant caveats. Gmail strips <picture> and <source> elements, so the fallback <img> inside may or may not survive. Outlook on Windows ignores <picture> but may still pick up the <img> tag. Apple Mail and most WebKit-based clients handle <picture> correctly. For reliable cross-client fallback, use MSO conditional comments or CDN content negotiation instead of relying on <picture>.

Does WebP support transparency for email logos?

WebP supports alpha channel transparency, but email clients handle WebP transparency inconsistently. Gmail's image proxy can flatten transparent areas to white. For logos and other transparent graphics in email, PNG remains the safer choice. Use WebP for opaque photographic content where its compression advantage is greatest.

What is the file size benefit of WebP in email?

WebP averages 25-34% smaller than JPG and 35-60% smaller than PNG at equivalent visual quality. For a typical email with three product images, switching to WebP can reduce image payload by 80-120 KB — meaningful for reducing email load time and staying under Gmail's 102 KB HTML clip threshold. See how to compress images without quality loss for additional optimization techniques.

Conclusion

WebP is a genuinely superior format for image compression, but email is not the web. The fragmented email client ecosystem — especially Outlook on Windows's complete lack of WebP support — makes naive WebP adoption a deliverability risk.

The practical path forward depends on your audience. For B2C lists with strong Gmail and Apple Mail representation, CDN content negotiation is the most elegant solution: a single image URL that serves the optimal format to each client. For mixed B2B/B2C lists with Outlook exposure, MSO conditional comments provide a reliable Outlook fallback while serving WebP everywhere else. For corporate-heavy lists, JPG and PNG remain the safest default.

Use the image converter hub to batch-convert campaign assets, the compress images tool to optimize whatever format you choose, and test aggressively before significant sends. The goal is the same regardless of format: fast-loading images that look correct in every inbox.

For further reading on image formats for digital delivery, see our guides on what is WebP format, best image format for email, and the full WebP conversion guide.