Where WebP Works Today

WebP is one of the most broadly supported image formats on the modern web. Global support sits above 97% of browser traffic, and every browser still under vendor support handles it natively. This guide gives you the current compatibility matrix, the cases that still need a fallback, and the patterns to ship WebP safely on any production site.

For where this fits in the broader performance picture, see WebP Optimisation. For the format itself, see WebP format overview.

Current support matrix

Support figures here reflect the state of the major browsers and rendering engines. They have been stable for several years — WebP is no longer an emerging format.

Desktop browsers

Browser	WebP lossy	WebP lossless	WebP animation	Notes
Chrome	✅ since 32	✅ since 32	✅ since 32	Native, no flag
Edge	✅ since 18	✅ since 18	✅ since 18	Chromium and legacy Edge
Firefox	✅ since 65	✅ since 65	✅ since 65
Safari (macOS)	✅ since 14	✅ since 14	✅ since 14	Big Sur and later
Opera	✅	✅	✅
Brave	✅	✅	✅	Chromium-based
Vivaldi	✅	✅	✅	Chromium-based

Mobile browsers

Browser	WebP lossy	WebP lossless	WebP animation	Notes
Chrome (Android)	✅	✅	✅	Default browser on most Android
Safari (iOS)	✅ since 14	✅ since 14	✅ since 14	iOS 14 released Sept 2020
Samsung Internet	✅	✅	✅	Chromium-based
Firefox (Android)	✅	✅	✅
UC Browser	✅	✅	⚠️ Partial	Animation support varies by build
Opera Mobile	✅	✅	✅

Operating system image viewers

Native OS support is less consistent than browser support:

macOS Big Sur (11) and later — Preview, Finder, Quick Look all support WebP.
macOS Catalina (10.15) and earlier — no native support. Third-party viewers required.
Windows 10 with Edge / Chrome — browsers handle it; native Photos app supports it via an optional codec pack.
Windows 11 — native support in Photos.
iOS 14+ — native support in Photos and Files.
Android 4.0+ — native support, with the caveat that early Android versions had partial lossless support.

OS-level support matters for end users who download images and view them outside the browser. This is the most common WebP friction point and the only remaining real-world case where users encounter the format and cannot open it.

What "97%+" means in practice

Global WebP support figures from caniuse and the StatCounter user-agent data sit between 97% and 98% of browser traffic. The remaining percentage is dominated by:

Older iOS versions (iOS 13 and earlier) — declining as users upgrade.
Internet Explorer 11 — no WebP support. Effectively zero traffic on consumer sites; non-trivial only on niche enterprise / government sites.
UC Browser on very old Android builds — concentrated in specific regions.
Embedded browsers (smart-TV browsers, game console browsers, in-app webviews on old phones) — long tail of edge cases.

For most public sites, ship WebP with a JPEG or PNG fallback via the <picture> element and you are covered. For sites with significant traffic from one of the buckets above (e.g. legacy enterprise customers on IE11, regional sites with old-Android user bases), the fallback matters more.

Detecting support

There are three reliable ways to detect WebP support, in decreasing order of preference.

1. The `<picture>` element (no detection required)

The browser does the detection for you, transparently:

<picture>
  <source srcset="image.webp" type="image/webp" />
  <img src="image.jpg" alt="Descriptive alt" />
</picture>

The browser inspects each <source> type attribute and selects the first format it supports. If WebP is not supported, the <img> fallback is used. No JavaScript, no flash of unstyled content, no detection script.

This is the right pattern for almost every WebP use case. Detection-based approaches are necessary only when you are loading images outside an <img> element — for example, as CSS backgrounds or canvas sources.

2. The `Accept` request header

When a browser fetches an image, it sends an Accept header indicating which formats it can render. WebP-capable browsers include image/webp:

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

Servers and CDNs can inspect this header and return different formats from the same URL:

Browser sends Accept: image/webp,... → server returns WebP.
Browser sends Accept: image/* without WebP → server returns JPEG.

This requires Vary: Accept on the response so caches store separate variants per Accept header. Most modern image CDNs (Cloudflare, Cloudinary, Imgix, Vercel) handle this automatically.

3. JavaScript feature detection

Use only when neither of the above patterns is viable — for example, when you need to know whether to load a WebP canvas resource.

async function supportsWebP(): Promise<boolean> {
  if (!self.createImageBitmap) return false;
  const blob = await fetch(
    "data:image/webp;base64,UklGRiQAAABXRUJQVlA4IBgAAAAwAQCdASoBAAEAAwA0JaQAA3AA/vshAAA="
  ).then((r) => r.blob());
  return createImageBitmap(blob).then(
    () => true,
    () => false
  );
}

This approach has trade-offs: it runs asynchronously, costs a microtask, and can produce inconsistent results in unusual edge cases. Use <picture> whenever possible.

Avoid older UA-sniffing detection scripts. They produce false negatives on modern browsers with unusual user agents (privacy-focused browsers, embedded webviews) and false positives on edge cases.

Fallback strategies

Pattern 1: `<picture>` element (recommended for all `<img>` use)

<picture>
  <source
    type="image/webp"
    srcset="
      /img/photo-800.webp 800w,
      /img/photo-1200.webp 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <img
    src="/img/photo-1200.jpg"
    srcset="/img/photo-800.jpg 800w, /img/photo-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="Descriptive alt"
    width="1200"
    height="675"
    loading="lazy"
    decoding="async"
  />
</picture>

Always include a fallback srcset on the inner <img> so non-WebP clients still benefit from responsive image selection. The width and height prevent layout shift — see Core Web Vitals & Images.

Pattern 2: Server-side content negotiation

A single URL, with the server returning WebP or JPEG based on Accept:

# Nginx example
map $http_accept $webp_suffix {
  default "";
  "~*image/webp" ".webp";
}

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

The server checks for .webp next to each requested JPEG/PNG. If present and the client accepts WebP, it serves the WebP. This is invisible to the HTML — <img src="photo.jpg"> returns WebP to capable clients.

Pattern 3: CSS background images

CSS does not support content negotiation natively. Three approaches:

JavaScript detection plus a class on <html>:

supportsWebP().then((ok) => {
  document.documentElement.classList.add(ok ? "webp" : "no-webp");
});

Then in CSS:

.hero { background-image: url("/img/hero.jpg"); }
.webp .hero { background-image: url("/img/hero.webp"); }

Avoid this if possible — it triggers a flash of unstyled background.

Server-side Accept negotiation on the CSS file itself, returning different background-image URLs.
image-set() with format hints:
```
.hero {
  background-image:
    image-set(
      url("/img/hero.webp") type("image/webp"),
      url("/img/hero.jpg") type("image/jpeg")
    );
}
```
image-set() with the type() syntax is supported in Chrome, Firefox, and Safari 16+. This is the cleanest CSS-native approach for new sites.

Edge cases worth knowing

Email clients

Email client support for WebP is dramatically worse than browser support. Apple Mail (macOS / iOS), Outlook on the web, and Gmail web/Android support WebP. Outlook desktop and older mail clients often do not. For email newsletters, stick to JPEG and PNG.

Some social media platforms transcode preview images server-side, so the format you ship in <meta property="og:image"> matters less than you might expect. To be safe, use JPEG or PNG for OG images — coverage is universal.

Print stylesheets

Most browsers handle WebP printing fine, but the long tail of corporate print drivers and PDF generators is uneven. For pages that are routinely printed (invoices, tickets, articles), test the print output or use a fallback.

Image SEO

Google indexes WebP images in Google Images and uses them for image search results. WebP is not a ranking risk. See Image SEO Best Practices.

When NOT to use WebP

Despite excellent support, a few content types are still better served by other formats:

Vector content — use SVG. WebP wins for raster, SVG wins for vector.
Animated content with very few frames — APNG sometimes wins for very short animations, though animated WebP usually beats it.
AVIF candidates — AVIF compresses better than WebP for photographic content at the cost of slower encoding and slightly narrower support. For sites that already ship modern formats, AVIF-with-WebP-fallback is the cutting edge.

Migration checklist

If you are moving an existing site to WebP:

Convert your library: PNG to WebP, JPG to WebP, GIF to WebP.
Replace <img> with <picture> for every image where you have a WebP variant.
Keep the original files in place — <picture> fallback needs them.
Add width and height to every fallback <img>.
Test on at least one non-WebP client (older Safari, IE11 if applicable).
Verify image SEO did not regress in Google Search Console.

Where to go from here

WebP Optimisation — broader performance guide
WebP Compression Settings — encoder parameter reference
Lossy vs Lossless — mode selection
WebP format overview — what the format actually is
Convert your content: PNG to WebP, JPG to WebP
Compare: WebP vs PNG

WebP browser support is no longer the limiting factor it was five years ago. With a <picture> element fallback, shipping WebP to production is a safe default for any public site today.