WebP Browser Support: Compatibility and Fallback Strategies

980 words 5 mins read

WebP is now supported across every major modern browser — Chrome, Firefox, Safari, Edge, and their mobile counterparts — giving you reliable coverage of more than 95% of global web users. Google shipped initial support in Chrome 23 back in 2012, and the last major holdout, Safari, added full support in version 14 (released with macOS Big Sur and iOS 14 in 2020). If you’re building for a general consumer audience today, you can confidently serve WebP as your primary image format as long as you have a sensible fallback in place for the small percentage of users on older platforms.

Browser Support Table #

The list below summarizes when each major browser added static WebP support:

Chrome — version 23. Lossy, lossless, and alpha support; animated WebP added in Chrome 32.
Firefox — version 65. Full support including animated WebP, all added simultaneously in Firefox 65.
Safari — version 14. macOS Big Sur (11) and iOS 14; all WebP types supported.
Edge — version 18. Chromium-based Edge (79+) has full support; legacy EdgeHTML had partial support from v18.
Opera — version 12.1. Early adopter; full support in all modern Opera versions.
iOS Safari — version 14. iPhone and iPad running iOS 14+; covers the vast majority of active iOS devices.
Android WebView — all modern versions. Bundled with Chrome on Android; supported on all devices running Android 4.2+ with updated WebView.
Samsung Internet — version 4.0. Based on Chromium; full support.

“Version added” refers to the first version with static WebP support. In some browsers (Chrome, Edge) animated WebP support arrived a few releases later; in others (Firefox, Safari) static and animated support shipped simultaneously. See the Animated WebP Support section below for details.

Checking Support Programmatically #

If you need to detect WebP support at runtime — for example, to dynamically swap image URLs in a JavaScript application — you can probe the browser by decoding a minimal WebP data URI and inspecting the result:

function checkWebPSupport(callback) {
  const img = new Image();
  img.onload = function() { callback(img.width > 0 && img.height > 0); };
  img.onerror = function() { callback(false); };
  img.src = 'data:image/webp;base64,UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA';
}

// Usage
checkWebPSupport(function(supported) {
  if (supported) {
    console.log('WebP is supported — serve .webp assets');
  } else {
    console.log('WebP not supported — fall back to JPEG/PNG');
  }
});

You can extend this pattern to test for lossless or animated WebP support by substituting the appropriate test data URI for each variant:

const TEST_URIS = {
  lossy: 'data:image/webp;base64,UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA',
  lossless: 'data:image/webp;base64,UklGRhIAAABXRUJQVlA4LAYAAAAwAQCdASoBAAEABUB8JZQCdAEO/gHOAAA=',
  animated: 'data:image/webp;base64,UklGRlYAAABXRUJQVlA4IEoAAADQAQCdASoCAAEAAkA4JZACdAEO/g3UAAD++P/ZGhAA',
};

function checkWebPVariant(variant, callback) {
  const img = new Image();
  img.onload = () => callback(img.width > 0);
  img.onerror = () => callback(false);
  img.src = TEST_URIS[variant];
}

Fallback Strategies #

Even with 95%+ global coverage, a production site should handle the remaining users gracefully. There are three mainstream approaches.

HTML <picture> Element (Recommended) #

The <picture> element lets you declare multiple source formats and lets the browser pick the first one it understands. Browsers that support WebP load the .webp source; everyone else falls through to the JPEG or PNG fallback:

<picture>
  <source srcset="image.webp" type="image/webp" />
  <source srcset="image.jpg" type="image/jpeg" />
  <img src="image.jpg" alt="A descriptive alt text" width="800" height="600" />
</picture>

The <picture> approach is the most reliable and widely recommended fallback strategy. It requires no JavaScript, no server configuration, and degrades cleanly in any browser — including very old ones that don’t understand <picture> at all, which will simply render the <img> tag inside it.

CSS image-set() #

For background images declared in CSS, use image-set() to provide format alternatives. Modern browsers pick WebP; others fall back to the second option:

.hero {
  background-image: url('hero.jpg'); /* ultimate fallback for very old browsers */
  background-image: image-set(
    url('hero.webp') type('image/webp'),
    url('hero.jpg') type('image/jpeg')
  );
}

Server-Side Content Negotiation #

Configure your web server or CDN to inspect the Accept request header. When a browser advertises image/webp in that header, the server responds with the WebP variant; otherwise it serves the original format. This approach keeps your HTML clean — you reference a single URL and the server handles the rest:

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

A typical Nginx configuration looks like this:

location ~* \.(jpe?g|png)$ {
  add_header Vary Accept;
  try_files $uri.webp $uri =404;
}

Server-side negotiation works best when combined with a build pipeline that automatically generates .webp counterparts alongside every original image. Tools like Sharp, ImageMagick, and Squoosh CLI integrate well into CI/CD workflows for this purpose.

Animated WebP Support #

Animated WebP support closely follows the static WebP rollout in every major browser, with a slight lag of one to three releases in some cases:

Chrome — version 32. Full animated support including alpha-per-frame.
Firefox — version 65. Static and animated WebP support shipped together in Firefox 65 (January 2019).
Safari — version 14. Both static and animated support arrived together.
Edge — version 18 (Chromium 79+). Full animated support in Chromium-based Edge.
Opera — version 19. Matched Chrome’s animated support timeline.
iOS Safari — version 14. Animated and static support added simultaneously.
Android WebView — Chrome 32 equivalent. Follows Chrome for Android release cadence.

When deploying animated WebP, always provide a GIF or APNG fallback using the <picture> element pattern — legacy Safari users (pre-14) and any browsers outside the support matrix above will need it:

<picture>
  <source srcset="animation.webp" type="image/webp" />
  <source srcset="animation.apng" type="image/apng" />
  <img src="animation.gif" alt="Descriptive alt text for the animation" />
</picture>

For a complete, production-ready implementation of the <picture> element fallback pattern — including responsive srcset, sizes, lazy loading, and CMS integration examples — see the HTML <picture> Element guide.

Was this page helpful?