WebP Browser Support in 2026: Exact Versions for Chrome, Safari, Firefox & Edge

You're about to switch your site's images to WebP and the question that stops you is the same one that's stopped developers for over a decade: will it actually work for everyone who visits the site? A few years ago that question had a real answer — Safari didn't support WebP, and a meaningful slice of your traffic would simply see broken images. Today the picture has changed dramatically, but old worries die hard, and a lot of teams are still adding fallback code for a problem that's mostly solved.

The honest answer requires knowing exactly which browser versions support WebP, since when, and where the small remaining gaps actually are — because "basically every browser" and "every browser" are different claims, and the difference matters if even a sliver of your traffic comes from older devices or corporate environments. WebP itself is no longer just a Google side-project either: the IETF formalized it as RFC 9649 in November 2024, which is worth knowing if anyone ever asks whether WebP is a "real" open standard or just a proprietary Google format.

What "browser support" actually means for WebP

A browser "supporting" WebP means it can natively decode the .webp file format and display it in an <img> tag, a CSS background-image, or inside a <picture> element — without any plugin, polyfill, or extra code. WebP is a raster image format Google built on top of the VP8 video codec it acquired with On2 Technologies, and it ships with the .webp file extension and the image/webp MIME type. In November 2024 the IETF formally standardized it as RFC 9649, which turned WebP from "a format Google documents" into a citable internet standard — though the reference encoder and decoder (libwebp) remain a Google-maintained open-source project.

WebP support isn't partial in the way some web features are: once a browser adds full support, it typically supports all of WebP's core capabilities at once — lossy compression, lossless compression, alpha transparency, and animation — in a single release, rather than rolling features out gradually. Chrome, Firefox, and Edge all followed this all-or-nothing pattern. Safari is the one partial exception worth knowing about: Safari 14 through 15 handles standard lossy WebP reliably, while some lossless and animated WebP edge cases weren't fully ironed out until Safari 16 shipped alongside macOS Ventura in 2022 — so if your site leans heavily on animated or lossless WebP and a chunk of your Mac traffic is still on Big Sur or Monterey, it's worth spot-checking there specifically.

The practical question, then, isn't "does WebP work" in the abstract — it's which specific browser versions your actual visitors are running, since support was added at meaningfully different times across browsers, spanning 2014 for Chrome to 2020 for Safari.

WebP support browser by browser

Here's exactly when each major browser added WebP, and what changed along the way.

Chrome

Chrome was first to support WebP, shipping lossy-only support in its early releases and reaching full support — lossy, lossless, alpha transparency, and animation — by Chrome 32 in 2014. That covers Windows, macOS, Linux, ChromeOS, and Android. Chrome for Android has carried WebP support since essentially its earliest Play Store builds, so Android traffic on Chrome is a non-issue.

Firefox

Firefox added WebP in Firefox 65, released in January 2019, across Windows, macOS, Linux, and Android. Unlike Chrome's gradual rollout, Mozilla shipped lossy, lossless, alpha, and animated WebP together in that same release, so feature detection in Firefox is effectively binary — if the version supports WebP at all, it supports all of it.

Safari

Safari was the last major holdout, and for years it was the entire reason "is WebP safe to use" was a real question. Support arrived in Safari 14 on macOS Big Sur and iOS 14, both released in September 2020. That single release is what pushed WebP from "mostly supported" to "safe to use by default" globally. Full lossless and animated WebP playback became more consistent starting with Safari 16 on macOS Ventura in 2022 — so for animation-heavy or lossless-heavy use cases specifically, Safari 16+ is the safer bar to target, even though basic lossy WebP has worked since version 14. Safari 13 and earlier do not support WebP in any form.

Microsoft Edge

Edge added WebP support in Edge 18 (2018) — coinciding with Edge's move to a Chromium base, which is also why it inherited Chrome's mature WebP implementation rather than building its own from scratch. The legacy EdgeHTML-based Edge (versions 12–17) did not support WebP, but that engine has been fully retired for years, so it's not a realistic concern for current traffic.

Opera and Samsung Internet

Opera added full WebP support in Opera 19 (2014), shortly after Chrome, since Opera also runs on Chromium's Blink engine. Samsung Internet has supported WebP since version 4, and on Galaxy devices it's one of the formats the browser actively negotiates for via the HTTP Accept header — meaning Samsung Internet users often receive WebP automatically even without explicit <picture> markup, as long as your server handles content negotiation.

Internet Explorer

Internet Explorer never added WebP support, in any version from IE 5.5 through IE 11. Microsoft has officially retired Internet Explorer, so in practice the only traffic still affected is legacy corporate, government, or kiosk software that hasn't migrated off it — environments that, notably, also won't self-select away from your site the way a consumer would.

Why browser support matters before you switch

Getting this wrong doesn't show up in testing on your own modern laptop — it shows up quietly, in production, for users you'll never directly observe:

• Broken images for unsupported visitors. Without a fallback, a browser that can't decode WebP simply fails to render the image — no warning, no graceful degradation, just a blank space or broken-image icon.
• Corporate and legacy environments. Some businesses, government systems, and kiosk software still run Internet Explorer or very old browser builds long after public support has ended, and these users won't self-select away from your site.
• Email rendering. WebP support in email is inconsistent — Gmail's web interface and current Apple Mail display it, but several Outlook builds, corporate Exchange setups, and older embedded webviews cannot. If your images appear in email campaigns, this is a separate consideration from web support.
• SEO and Core Web Vitals. Search engines and performance audits (including Google PageSpeed Insights) increasingly flag JPEG/PNG-only sites for missed compression opportunities — but only if WebP is implemented in a way that's actually compatible with the audited browser.

Step-by-step: how to safely roll out WebP

1. Check your own traffic data first. Before worrying about global averages, look at your site's analytics for browser and OS version breakdowns. If your audience skews modern — which most does in 2026 — your real-world WebP support is likely at or above the global 97% figure.
2. Convert your images to WebP. Use a design tool with native export (modern Photoshop 23.2+, Figma, GIMP) or a dedicated converter. Lossy WebP at quality 75–85 mirrors the JPEG sweet spot; use lossless WebP for graphics that currently live as PNG.
3. Add a fallback using the <picture> element. This lets the browser request the WebP source first and silently fall back to JPEG or PNG if WebP isn't supported — no JavaScript required, and zero visible difference to the end user either way.
4. Use srcset for a lighter-weight alternative. If <picture> feels heavy for your workflow, the <img srcset> pattern achieves the same effect with less markup, letting supporting browsers pick WebP and others fall back automatically.
5. Decide separately about email. Don't reuse your web image pipeline for email campaigns. Keep email images as JPEG or PNG unless you've specifically tested WebP rendering across your actual recipient list's email clients.
6. Test on real browser versions, not just current ones. Tools like BrowserStack, LambdaTest, or caniuse.com let you verify rendering on older Safari or legacy Edge builds if a meaningful chunk of your traffic still uses them.
7. Monitor after launch. Check server logs or a real-user-monitoring tool for image load failures after rollout. This catches edge cases (specific corporate proxies, embedded browsers, older devices) that synthetic testing can miss.

How to check if a browser supports WebP

You don't need to guess or rely on parsing a user-agent string — the most reliable check loads a tiny WebP image directly and asks the browser whether it decoded successfully. Here's a snippet you can drop straight into a script or browser console:

function supportsWebP(callback) {
  const img = new Image();
  img.onload = () => callback(img.width === 2 && img.height === 1);
  img.onerror = () => callback(false);
  img.src =
    "data:image/webp;base64,UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==";
}

supportsWebP((isSupported) => {
  console.log("WebP supported:", isSupported);
});

In production you rarely need to run this yourself, though — the <picture> element does the same job natively, with no script execution or layout shift:

<picture>
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description of the photo">
</picture>

The browser requests photo.webp if it can decode WebP, and quietly falls back to photo.jpg if it can't — no JavaScript, no flash of missing content, no extra request in supporting browsers. If the JavaScript snippet above logs false on a browser you expect to support WebP, check that the data URL isn't being blocked by a Content Security Policy that restricts img-src to https-only sources.

Common mistakes that break images for some users

1. Switching to WebP with no fallback at all

With 97%+ support, it's tempting to skip the fallback entirely. But for the remaining visitors — Internet Explorer in corporate settings, very old Safari on unsupported Macs — the image simply doesn't load. A <picture> fallback costs almost nothing to add and eliminates this risk completely.

2. Assuming WebP works the same way in email as on the web

Web browser support and email client support are entirely separate ecosystems. Many email clients, including several Outlook versions and older embedded webviews, render WebP unreliably or not at all. Treating an email template like a web page is a common source of broken newsletter images.

3. Using JavaScript feature-detection when it's not needed

Checking WebP support with a JavaScript canvas or Image test was once a reasonable approach, but with native browser support this universal, it's usually unnecessary overhead for production. The <picture> element handles the same fallback logic natively — save the JS snippet for debugging, not for shipping.

4. Forgetting that "supported" doesn't mean "identical everywhere"

Even within supporting browsers, older minor versions sometimes have rendering quirks with animated or lossless WebP — Safari before version 16 is the main example. If your site relies heavily on animated WebP for critical UI, spot-check on a few older supported versions, not just the latest release, and keep a static poster frame as backup.

Real-world examples

How WebP support actually plays out across different real-world scenarios:

The pattern across all of these: WebP support is high enough almost everywhere that it's safe to adopt as a primary format, but the size of the small remaining gap — and whether it's worth a fallback — depends entirely on who actually visits your site.

WebP vs JPEG vs PNG vs AVIF

WebP, JPEG, PNG, and AVIF all serve images on the web, but they differ on compression, transparency, animation, and browser reach. This is where the version numbers above actually matter in practice.

See the full WebP vs JPEG breakdown → and the WebP vs PNG comparison → for deeper dives on either pairing.

Known issues and edge cases

WebP is supported in every major browser, but real-world delivery still has a few rough edges worth planning around.

• No Internet Explorer support. IE cannot decode WebP in any context. Sites that still target enterprise IE fleets need a JPEG, PNG, or GIF fallback inside a <picture> source list.
• Older Safari and animated/lossless WebP. Safari 14-15 plays standard lossy WebP reliably, but some lossless and animated WebP cases only became consistent from Safari 16 onward. Pair animated WebP with a static poster frame as a safety net for older Safari.
• Animated WebP isn't always the smallest option. It beats GIF on file size, but for loops longer than a few seconds it can lose out to animated AVIF or a short MP4. Worth profiling before committing.
• Image editor friction. Adobe Photoshop needs version 23.2 or later for native WebP export, and some older Windows editors still require a separate WebP codec pack.
• Email client coverage is patchy. Gmail's web interface and current Apple Mail render WebP, but several Outlook builds and embedded webview clients still need a fallback — test campaigns before sending.
• Older Windows builds treat WebP as a download. Windows 8.1 and early Windows 10 builds may prompt a download instead of opening WebP in Photos; users need the WebP Image Extensions package from the Microsoft Store.

Convert your images to WebP right now — free

The Rebrixe Image Converter runs entirely in your browser. Convert JPEG or PNG to WebP, or go the other direction for compatibility testing — your images are never uploaded to a server. No account, no file size limit, no watermarks.

Frequently asked questions

Sources

Version numbers and format details in this guide are drawn from these primary sources:

• IETF RFC 9649 — WebP Image Format: rfc-editor.org/rfc/rfc9649
• Google Developers — WebP FAQ: developers.google.com/speed/webp/faq
• MDN Web Docs — Image file type and format guide: developer.mozilla.org
• WebKit Blog — New WebKit Features in Safari 14 and 16: webkit.org/blog
• Mozilla — Firefox 65 Release Notes: mozilla.org/en-US/firefox/65.0/releasenotes