WebP Format: Compression, Browser Support & Use Cases

Origin and adoption

WebP was announced by Google in September 2010 as a derivative of the VP8 video codec, which Google had acquired earlier that year through the purchase of On2 Technologies. The intent was direct: the web's two dominant image formats — JPEG and PNG — had not seen meaningful compression improvements in nearly two decades, while video codecs had advanced dramatically. WebP was an attempt to apply modern video compression techniques to still images.

The first stable release shipped in early 2011 with lossy compression only. Lossless and animation support were added in 2012. Alpha channel support landed soon after. By 2014, every major Google property — Gmail, YouTube thumbnails, Google Play, Image Search results — was serving WebP to capable clients.

Browser adoption took longer. Chrome supported it from the start. Opera followed quickly. Firefox added support in version 65 (January 2019). Safari, the long holdout, added support in version 14 (September 2020) on macOS Big Sur and iOS 14. As of 2026, global browser support sits above 97% of all traffic, with the remaining percentage concentrated in deprecated browsers and embedded webviews on legacy devices. Detailed coverage is in WebP Browser Support.

Container structure

A WebP file is a RIFF (Resource Interchange File Format) container — the same container family as WAV audio files. The basic structure is a header chunk followed by one or more payload chunks.

For a simple lossy image, the file contains:

RIFF header (4 bytes) identifying the format.
File size (4 bytes).
WEBP identifier (4 bytes).
VP8 chunk containing the actual lossy image data.

For lossless, the payload chunk is VP8L. For images with transparency or animation, additional chunks (ALPH, ANIM, ANMF) extend the structure.

The RIFF container makes WebP extensible without breaking compatibility. New chunk types can be added (and have been, for animation and ICC colour profiles) without requiring decoders to update — unknown chunks are simply skipped.

The lossy codec (VP8)

WebP's lossy mode uses VP8, the same codec that powers WebM video. VP8 is a block-based predictive codec. The encoder splits each image into 16×16 pixel macroblocks, then predicts the contents of each block from its neighbours using one of several prediction modes. Only the difference between the prediction and the actual content — the "residual" — is quantised and stored.

This approach is fundamentally different from JPEG. JPEG operates on 8×8 blocks independently, encoding each block's DCT coefficients in isolation. VP8's neighbour-aware prediction means a block in the middle of a smooth gradient can be predicted nearly perfectly from its surroundings, leaving almost no residual to encode. JPEG cannot exploit that redundancy.

The result, at typical quality settings, is 25–35% smaller files than JPEG with visually equivalent quality. The advantage is most pronounced on smooth-toned content where prediction is highly effective, and least pronounced on noisy or highly textured content where prediction provides little benefit.

The detailed parameter surface for the lossy encoder is documented in WebP Compression Settings.

The lossless codec

WebP's lossless mode is unrelated to VP8 and was developed specifically for the format. It combines several techniques:

Spatial prediction — every pixel is encoded as the difference from a function of its already-decoded neighbours, using one of 14 predictor modes per region.
Colour transform — exploits correlation between R, G, and B by storing one channel as a function of another.
Subtract-green transform — for photographic content, encodes R and B relative to G. Photographs tend to have green-dominant luminance, so subtracting G leaves smaller residuals for R and B.
Colour indexing — for images with 256 or fewer colours, an index palette replaces full RGB values.
LZ77 backward references — finds and refers to repeated pixel sequences, the same family of technique used in PNG's DEFLATE compression.

The end result is roughly 25% smaller than PNG at bit-identical fidelity. For images with limited palette and many flat fills (logos, icons, UI screenshots), the saving can be larger.

Transparency

WebP supports a full 8-bit alpha channel — the same range PNG offers, dramatically more than GIF's 1-bit binary transparency. Alpha can be encoded losslessly even within a lossy WebP file, by setting the alpha quality independently from the RGB quality. This is uniquely valuable for content like logos on photographic backgrounds, where the alpha edges need to stay sharp but the RGB content can tolerate lossy compression.

Animation

WebP supports animation via the ANIM and ANMF chunks. Each frame can be encoded as lossy or lossless, and frames can blend over previous frames (a feature GIF lacks). Animated WebP files routinely beat animated GIFs by 30–60% in file size at higher quality.

For migrating animated GIF content, see GIF to WebP. For the broader decision around animated formats, animated WebP has largely replaced animated GIF in modern web usage, with the notable exception of meme distribution where GIF's universal embedding support still wins.

Ecosystem support

WebP encoding and decoding is supported in every mainstream tooling stack:

libwebp — Google's reference C library, used by browsers and most image tools.
Sharp (Node.js) — production-grade image pipeline used by most modern build tools and frameworks.
ImageMagick / GraphicsMagick — universal CLI image tools with WebP support.
Pillow (Python) — image library used throughout Python web stacks.
Squoosh — Google's browser-based interactive encoder, useful for tuning.
Adobe Photoshop — native WebP support since 23.2 (February 2022).
GIMP — native WebP since 2.10.
Affinity Photo, Pixelmator Pro, Sketch, Figma — all support WebP import and export.

CDN providers — Cloudflare, Cloudinary, Imgix, Fastly, Vercel — all support automatic JPEG-to-WebP conversion with Accept-header content negotiation. This is the lowest-effort path to shipping WebP if you cannot retool your build pipeline.

Implementation patterns

The recommended way to ship WebP today is the <picture> element with a JPEG or PNG fallback:

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

The browser picks the first format it supports — WebP for clients that handle it, the fallback <img> for clients that do not. No JavaScript detection required.

For server-side content negotiation (one URL, format chosen per Accept header), see WebP Browser Support. For framework-specific integration (Next.js, Astro, React), the framework image components handle WebP delivery automatically — see WebP in React.

CSS support

WebP can be used in any CSS property that accepts an image URL:

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

For content-negotiated delivery in CSS, use image-set() with format hints:

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

The browser selects the first format it supports. image-set() with type() is supported in Chrome, Firefox, and Safari 16+.

Performance characteristics

The performance benefit of WebP is heavily content-dependent.

Photographic content — 25–35% smaller than equivalent JPEG, typically.
Logos and icons — 25% smaller than equivalent PNG, often more for content with limited palette.
Screenshots with text — variable. Near-lossless mode usually best.
Already heavily compressed JPEGs — diminishing returns. The encoder cannot reclaim what is not there.

The decode performance of WebP is comparable to JPEG and PNG on modern hardware. On low-end mobile devices, lossless WebP decoding can be slightly slower than PNG due to the predictor transforms. For most real-world traffic this is imperceptible.

For the broader performance framework, including how WebP affects Core Web Vitals, see Core Web Vitals & Images.

Comparison to other modern image formats

WebP is not the only modern image format competing for adoption. Three others matter:

HEIC / HEIF

The default photo format on iPhones since iOS 11. Based on the HEVC video codec, HEIC compresses photographic content 30–50% smaller than JPEG. Browser support is essentially nonexistent — Safari can decode HEIC images via the OS but does not advertise it through the image/heic MIME type to web pages. As a result, HEIC is widespread as a camera output format but rare as a web delivery format. Most web image pipelines convert HEIC to JPEG or WebP at upload.

AVIF

Released in 2019, based on the AV1 video codec. AVIF compresses photographic content 20–30% smaller than WebP at equivalent quality — the best size-to-quality ratio of any current web image format. Browser support reached production levels in 2022. The trade-offs against WebP:

AVIF decoding is slower than WebP decoding, particularly on low-end mobile devices. On constrained hardware the byte savings can be offset by longer decode times.
AVIF encoding is dramatically slower than WebP encoding. Build pipelines that encode many images may see noticeable build-time impact.
AVIF support, while broad, is still slightly behind WebP — typically 94–95% of traffic versus WebP's 97%+.

The state-of-the-art pattern in 2026 is to ship AVIF with a WebP fallback and a JPEG fallback below that:

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

WebP remains the right primary choice for most sites because the marginal byte saving from adding AVIF is small once WebP is already in place, and the encoding cost is real.

JPEG XL

A different design philosophy: a single format that handles lossy, lossless, and even progressive decoding from a JPEG-compatible bitstream. Encoders can losslessly recompress existing JPEGs to roughly 20% smaller files without quality loss. Browser support is the obstacle — Chrome shipped support, removed it, and as of 2026 it remains behind flags in most browsers. Not a viable web delivery format today.

WebP in CMS pipelines

The major CMS platforms have varying degrees of native WebP support:

WordPress — supports WebP uploads natively since 5.8. Several plugins (ShortPixel, Imagify, WP Rocket, EWWW) automate JPEG/PNG-to-WebP conversion and serve via the <picture> element. Detailed guidance in WebP on WordPress.
Shopify — automatically serves WebP from the Shopify CDN with Accept-header negotiation. No theme changes required. See WebP on Shopify.
Magento / Adobe Commerce — supports WebP via image processing extensions and the built-in image transformation API since version 2.4.
Drupal — native WebP image style derivative support since version 9.
Contentful, Sanity, Strapi — headless CMS platforms typically serve WebP through their built-in image CDN with on-the-fly transformation.
Static site generators (Next.js, Astro, Eleventy, Hugo) — all ship with native image components or modules that handle WebP delivery automatically. See WebP in React.

For any of these, the WebP delivery pipeline is largely automatic. The configuration choices are usually limited to compression quality, fallback format, and which images to skip (typically OG images and email content).

Tooling for inspection

Verifying a WebP file's structure and content is straightforward with the official tools:

webpinfo — dumps the chunk structure of a WebP file. Confirms whether it is lossy, lossless, animated, or contains transparency.
dwebp — decodes a WebP file to PNG. Useful for round-trip testing and visual comparison.
gif2webp — converts animated GIFs to animated WebP.
img2webp — builds animated WebP from a sequence of still images.

# Inspect file structure
webpinfo photo.webp

# Decode to PNG for inspection
dwebp photo.webp -o photo.png

For pixel-level comparison against the source, Squoosh accepts two images and shows side-by-side and pixel-difference views.

When to use WebP

The short answer: almost always, for any raster image on a public-facing web page.

Photographic content — use lossy WebP at q=75–85.
Logos, icons, line art — use lossless WebP.
Animated content — use animated WebP (replace animated GIF entirely).
Vector content — use SVG instead. WebP wins for raster; SVG wins for vector.
Email — stick to JPEG/PNG. Email client WebP support is patchy.
Open Graph images — stick to JPEG/PNG. Social previews are inconsistent with WebP.

For the systematic mode-choice framework, see Lossy vs Lossless.

Converters

Tools on this site for converting to and from WebP:

WebP to PNG, WebP to JPG, WebP to GIF, WebP to ICO
PNG to WebP, JPG to WebP, GIF to WebP, ICO to WebP
Compress WebP — re-encode existing WebP files at a different quality to shrink them further