WebP Browser Support

The state of WebP support today

As of May 2026, static WebP sits at roughly 98% global browser support according to caniuse.com/webp. Animated WebP trails slightly at around 97% per caniuse.com/webp-animation. Both numbers have been essentially flat since late 2021, when Safari shipped animated support and closed the last major gap.

The remaining 2–3% is almost entirely Internet Explorer (officially retired by Microsoft in June 2022 but still lurking in enterprise environments), a handful of older Samsung Internet versions, and some stale Android WebViews on devices that never received OS updates.

For most web projects today, you can serve WebP confidently without a fallback and lose almost nothing. Whether that 2–3% gap matters depends on your audience — more on that in the fallback sections below.

Static vs. animated: they are tracked separately

Caniuse treats static WebP and animated WebP as two distinct feature entries, because browsers genuinely shipped them at different times. Safari is the clearest example: it added static WebP in version 14 (released September 2020) but didn't ship animated WebP until 14.1 (April 2021). That seven-month gap was small in absolute terms, but it meant that for a period, a Safari user could display a WebP thumbnail but not a WebP animation.

Why does the distinction matter in practice? It determines what fallback you actually need. If you're serving a product thumbnail or an Open Graph image, static support at ~98% is probably sufficient and no fallback is required for most audiences. If you're serving a hero animation — a looping video replacement — you need animated support, and your target floor is ~97%. That 1% difference is real: it corresponds to browser versions still in active use on some mobile devices.

Check both feature pages on caniuse before deciding. The global percentages are split by browser version weighted against actual usage data, so they're more accurate than a raw list of supported versions.

Browser-by-browser timeline

The headline takeaway: Chrome shipped WebP more than a decade ago and has never had issues with it. Firefox was late but landed both formats at once in 2019. Safari held out until 2020–2021 and remains the browser most likely to surface edge-case bugs. Every Chromium-based browser (Edge, Opera, Samsung Internet, Brave, Arc) inherits Chrome's codec and has comprehensive support.

Safari's late arrival and what's still flaky

Safari was the last major browser to ship WebP, and the delay was not subtle — Chrome had support for six years before Safari caught up. Apple's reluctance was partly political (WebP is a Google format) and partly technical (their existing image pipeline was tuned for JPEG and HEIC). When they finally added it in Safari 14 on macOS Big Sur and iOS 14, the implementation was functional but not polished.

A few issues are still worth knowing about. First, decoding artifacts: on older iOS 14 and 14.1 devices (iPhone 7 and earlier, specifically), some animated WebP files with transparency render with a faint green fringe on certain frames. It's rare, but it happens with files produced by older encoders that don't pad alpha channels correctly. If you're targeting that user base, test with a device or a simulator.

Second, some third-party Safari extensions — particularly ad blockers that intercept image requests — occasionally mishandle the image/webp MIME type and serve a broken image instead of falling through to the source tag. This is an extension bug, not a Safari bug, but users see a broken image on your page.

Third: as of macOS Sequoia, Quick Look in Finder still does not preview WebP files. It shows a generic icon. This matters if you're building tooling or documentation aimed at non-developer users who work with files locally — they'll assume the file is corrupted. It's a known Apple omission with no announced fix date.

The <picture> fallback pattern

For the roughly 3% of users who still land on a browser without WebP support, the <picture> element is the canonical solution. The browser reads the <source> tags in order and uses the first one it supports. If none match, it falls back to the <img> tag.

<picture>
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.gif" alt="..." />
</picture>

This pattern works because browsers that don't understand type="image/webp" skip that source tag entirely and land on the <img>. The GIF is only downloaded by browsers that don't support WebP — modern browsers download only the WebP.

You can extend this to a triple-fallback if you also want to target AVIF-capable browsers (Chrome 85+, Firefox 93+), which compress even better than WebP for static images:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.gif" alt="..." />
</picture>

For animated content specifically, AVIF animation support is still inconsistent (Firefox and Chrome yes, Safari no as of 2026), so WebP remains the safer animated format to feature-detect. Use the AVIF source for static images only unless you have tested your specific audience.

The Accept content-negotiation pattern

Browsers that support WebP include it in the HTTP Accept request header:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

A server-side image pipeline can inspect that header and return a WebP version when the client advertises support, or fall back to JPEG/PNG/GIF when it doesn't. The response URL stays the same — only the content changes. This approach is attractive because it requires no HTML changes: existing <img> tags automatically get the right format.

CDNs make this mostly automatic. Cloudflare Polish rewrites images to WebP on the fly when the client's Accept header includes image/webp. Cloudflare Image Resizing does the same through the /cdn-cgi/image/ transformation URL. Similar behavior is available in Fastly, Imgix, and Cloudinary.

The one trade-off: caches need to be aware that the same URL can return different content. If your CDN or reverse proxy caches images without keying on the Accept header, some users will receive the wrong format. The fix is to add Vary: Accept to image responses, which tells intermediary caches to store separate copies per Accept value. Most CDNs handle this automatically when you enable their WebP conversion features.

Mobile WebView caveats

Native mobile apps that embed web content use a WebView component, and WebView behavior is not identical to the system browser. On Android, the Android System WebView is the component that powers embedded web content in apps. It tracks Chrome's release schedule, but on devices that haven't received recent OS security patches, the WebView can lag 1–2 Chrome versions behind. On most Android 5+ devices this is a non-issue for WebP, since even Chrome 32 supported it. The realistic problem is older Android 4.x devices, which are genuinely out in the world (estimated at under 1% of Android traffic as of 2026 but not zero).

Animated WebP specifically can fail to render in very old Android WebViews even when the WebView claims Chromium-based lineage, because the animated decoder was added later in the pipeline. If your app targets Android 4.4 or earlier, do not assume animated WebP works inside a WebView without testing.

On iOS, the picture is cleaner. UIWebView — Apple's older embedding API — does not render WebP at all, but Apple deprecated UIWebView in iOS 12 (2018) and removed it from the App Store review guidelines in 2020. Any app still shipping UIWebView is not compliant and likely years out of date. WKWebView, the replacement used by every modern iOS app, renders WebP using the same engine as Safari, which means full support since iOS 14.

If you are building a hybrid app (Capacitor, Cordova, React Native WebView), test your target WebView explicitly rather than assuming it matches the current Safari or Chrome version.

Decoder cost on low-end devices

Animated WebP decodes on the CPU, frame by frame. On modern mid-range hardware this is invisible. On a low-end 2020-era Android device — think a $100 entry-level phone with a budget Snapdragon — a 60-frame animated WebP looping at 24 fps can spike CPU usage to 8–10% while the animation plays. If that animation is in a page scroll context and the device is simultaneously rendering the rest of the page, you will see dropped frames.

The comparison point matters here. GIF decodes on the CPU too, and its decoder is less efficient than WebP's on most devices. An equivalent GIF will use more CPU and more memory due to the larger file size. So the trade-off is not "WebP hurts performance vs. nothing" — it is "WebP is more efficient than GIF, but an <video>tag with hardware-accelerated H.264 or AV1 uses essentially no CPU."

Practical guidance: for long animations or animations in battery-sensitive contexts (mobile carousels, infinite-scroll feeds), consider a <video autoplay loop muted playsinline> instead. For short looping animations under 3 seconds where the GIF replacement use case is clear, animated WebP is the right tool. See animated WebP vs. GIF and optimal encoding settings for the detailed trade-offs.