What Is WebP? The Complete Guide to Google's Image Format (2026)

You've probably loaded thousands of WebP images without realizing it. Open any major site in Chrome — YouTube, Wikipedia, Amazon — and inspect the images in DevTools. Most are served as WebP, even when the src attribute still says .jpg. Content negotiation handles the swap silently. It's not a niche format anymore. It's the default.

The question isn't really whether to use WebP — the answer is yes, for almost everything. The harder questions are: how does the compression actually work, when does WebP make things worse (email is a trap most developers fall into), and how do you implement it correctly in your specific stack. That's what this guide covers, from the VP8 encoding internals to copy-paste code for WordPress, Shopify, and Next.js.

1. What Is WebP?

WebP — pronounced "weppy" — came out of Google's 2010 acquisition of On2 Technologies. On2 built VP8, a video codec that compressed individual frames with remarkable efficiency. Google's engineers saw the obvious: compressing a video keyframe is the same problem as compressing a still image. Strip out the temporal prediction (the parts that reference neighboring frames), keep the spatial compression engine, and you have a still image format. That's WebP. It was released September 30, 2010, and formally standardized as RFC 9649 by the IETF in 2024.

What made it interesting from day one: it wasn't designed to replace just JPEG or just PNG. JPEG handles photos, PNG handles transparency and lossless graphics, GIF handles animation. WebP does all three — in one format, almost always at a smaller file size than any of them.

The 41.3% compression gain figure comes from Google's own analysis of one million real-world web images, comparing WebP lossy encoding to JPEG at matched visual quality settings. That's not a cherry-picked benchmark — it's an average across a wide range of image types, lighting conditions, and content categories. For a website with 200 images averaging 200KB each, that's roughly 16MB of bandwidth saved per page load cycle — and the savings compound across every visitor.

WebP files use the .webp extension and the MIME type image/webp. Under the hood they use a RIFF container — the magic bytes "RIFF" sit at bytes 0–3, "WEBP" at bytes 8–11. That header means any system can identify the format reliably without trusting the file extension.

2. A Brief History of WebP

Understanding WebP's history helps explain why it took so long to reach universal browser adoption — and why 2020 was such a pivotal year for web image optimization.

3. How WebP Compression Works

WebP doesn't use a single compression algorithm — it uses two entirely separate algorithms depending on whether you're encoding lossy or lossless, plus a container format that wraps them together. Understanding this distinction is key to using WebP correctly.

Lossy Compression: VP8 Key Frame Encoding

WebP's lossy mode uses VP8's intra-frame encoding — the same algorithm that compresses individual frames in H.264-based video. The core principle is predictive coding: instead of storing the actual value of each pixel, the encoder looks at neighboring pixels that have already been encoded and predicts what the current pixel's value should be, then stores only the difference (the "residual") between the prediction and the actual value. Good predictions produce very small residuals, and small residuals compress efficiently.

The image is divided into macroblocks — 16×16 pixel blocks for luma (brightness) information and 8×8 blocks for chroma (color) information. Each macroblock can be further subdivided into 4×4 sub-blocks. For each block, the encoder tries several prediction modes (horizontal, vertical, DC average, and others) and picks the one that produces the smallest residual. This is computationally expensive — which is why WebP encoding is slower than JPEG encoding — but the result is a much more compact representation of the image.

The color space used is YUV 4:2:0, the same as H.264 video — where luma (Y) is stored at full resolution but chroma (U and V, representing color) is stored at half resolution in each dimension. Human eyes are far more sensitive to brightness changes than color changes, so this 4:2:0 subsampling is essentially invisible at normal viewing distances while reducing the data to encode by a third.

The residuals from the predictive coding step are then transformed using a Discrete Cosine Transform (DCT), which converts the spatial data into frequency components. High-frequency components (fine details the eye struggles to perceive) are quantized aggressively, discarding imperceptible data. This is the "lossy" step — the quantization is irreversible. Finally, the quantized coefficients are compressed using arithmetic entropy coding, which is more efficient than the Huffman coding used by JPEG.

Lossless Compression: VP8L

WebP's lossless mode uses a completely different algorithm called VP8L, designed by Jyrki Alakuijala at Google (who also co-created the Zopfli and Brotli compression algorithms). Unlike VP8, which works in YUV color space, VP8L works directly with RGBA values — red, green, blue, and alpha, each stored as an 8-bit value (0–255).

VP8L achieves its impressive compression ratios through a combination of techniques applied in sequence:

• 2D backward references (LZ77 variant) — The encoder can reference already-encoded image fragments when similar patterns repeat. Unlike LZ77's 1D sliding window, VP8L can reference blocks in two dimensions — both earlier in the same row and in previous rows. This is particularly effective for images with repeating textures or large uniform areas.
• Color transform — A color transformation stage reduces correlation between color channels, making the remaining data more compressible. The encoder predicts each channel's value from the others and stores the prediction error.
• Color cache — A palette of recently used colors is maintained as a hash table. When a color appears again, it can be referenced by its cache index rather than its full RGBA value — dramatically reducing data for images with limited palettes.
• Huffman coding — The final stage applies Huffman coding to the output stream, with different Huffman trees potentially used for different spatial regions of the image.

The result is a lossless image that is, on average, 26% smaller than an equivalent PNG. No pixel data is discarded — every RGBA value is preserved exactly. This makes VP8L ideal for screenshots, icons, logos, and any image where pixel-precise accuracy is required.

The RIFF Container Format

Both VP8 and VP8L bitstreams are wrapped inside a RIFF container — the Resource Interchange File Format originally developed by IBM and Microsoft in 1991. A WebP file always begins with the 4-byte ASCII string RIFF, followed by the file size, followed by WEBP at bytes 8–11. This header structure makes WebP files immediately identifiable.

Inside the RIFF container, different chunk types are used depending on the features present:

• VP8 — Simple lossy WebP (note the trailing space). Contains the raw VP8 bitstream.
• VP8L — Simple lossless WebP. Contains the raw VP8L bitstream.
• VP8X — Extended WebP format. This chunk is used when the file uses any extended features: animation, transparency in a lossy image, metadata (Exif/XMP), or an ICC color profile. It contains flags indicating which optional features are present, followed by additional chunks (ANIM, ANMF, ALPH, ICCP, EXIF, XMP ) that carry the corresponding data.

This chunk-based extensibility is what allowed Google to add animation and metadata support to WebP in 2011 without breaking existing decoders — decoders simply skip chunks they don't recognize.

4. Key Features of WebP

JPEG does one thing. PNG does one thing. GIF does one thing, badly. WebP was built to cover all of them — and it mostly succeeds.

The combination of lossy transparency is worth dwelling on because it's genuinely novel. JPEG cannot be transparent at all — if you need a photo of a product on a white background, JPEG just bakes the white in. PNG can be transparent, but only in lossless mode — so a 3MB PNG product photo with a transparent background stays 3MB. WebP can give you that same transparent product photo at 25–35% of the PNG's size, using lossy compression for the photographic content while maintaining a clean alpha edge. For e-commerce sites with thousands of product images, this difference is commercially significant.

5. WebP vs JPG

JPEG is 34 years old. That's not a criticism — it survived because it works. But it was built for a world of dial-up connections and small monitors, and compression science has moved on considerably since 1992.

File size is where you feel the difference immediately. A 200KB JPEG hero image typically becomes 120–150KB as WebP at the same visual quality — no perceptible change, just a smaller file. Google analyzed a million real-world images and found 41.3% average compression gain over JPEG. Across a page with 20 images, that's several megabytes saved per load, per visitor.

Push compression harder and the gap gets more obvious. JPEG at low quality develops blocky artifacts — that ugly 8×8 grid pattern you've seen on low-budget sites. WebP degrades much more gracefully. At quality 60, WebP typically looks cleaner than JPEG at 75–80. That means you can compress WebP further without ruining the image, which compounds the file size advantage.

Two things JPEG simply can't do: transparency and animation. A JPEG is always a solid rectangle — no alpha channel, ever. WebP supports full 8-bit transparency in both lossy and lossless modes. Need a product photo with a cutout background? With JPEG you're forced to use PNG (and accept a much larger file). WebP handles it in one format at JPEG-like file sizes.

Where JPEG still wins: encoding speed (3–5× faster than WebP, which matters for real-time image resizing), and email. No major email client supports WebP — Outlook, Gmail, Apple Mail, Yahoo. Newsletters and transactional emails must stay on JPEG or PNG, full stop.

Use JPEG when: sending images by email, setting og:image for social media sharing, sharing photos to platforms that don't accept WebP (some print services, older software), or generating thumbnails in real-time on a performance-constrained server.

Use WebP when: everything else on the web — product images, hero photos, blog images, thumbnails, transparent graphics, and animated images.

6. WebP vs PNG

PNG is the format you reach for when JPEG is wrong — when you need transparency, or when you can't afford any quality loss. Screenshots, logos, interface graphics, product cutouts. It's always lossless, which means pixel-perfect accuracy. It's also why PNG files are big.

WebP's lossless mode directly challenges PNG's position. Using the VP8L algorithm, WebP lossless produces files that are 26% smaller than equivalent PNG files — with the exact same pixel data. For a 500KB PNG logo with transparency, that means a 370KB WebP file with identical visual quality. No data is discarded. The pixels are identical. The WebP is just encoded more efficiently.

For photographic content with a transparent background (like product cutout photos), WebP has an even larger advantage. PNG must use lossless compression for the entire image, including the photographic detail. WebP can use lossy compression for the photographic content while maintaining a clean alpha channel — producing files that are 4–10× smaller than the equivalent PNG, with only minimal perceptible quality loss in the non-transparent areas.

The area where PNG still holds an advantage is software compatibility. PNG is supported by every image editor ever made — Photoshop, GIMP, Affinity Photo, Sketch, Microsoft Paint, everything. WebP support in design tools has improved dramatically since 2020, but if you're working with files that will be opened, edited, and re-saved in multiple tools, PNG remains the safer choice for working files. Convert to WebP at the final export stage, not for your source files.

7. WebP vs GIF (Animated Images)

GIF is 38 years old and it shows. 256 colors per frame, 1-bit transparency (pixels are either fully transparent or fully opaque — no gradients), and file sizes that are embarrassingly large for what they actually display. The only reason GIF survives is cultural inertia — it became the meme format before better options existed, and the sharing infrastructure got built around it.

The numbers are hard to defend. A 2-second animation at 720×480 runs 3–5MB as a GIF. The same animation as animated WebP: around 700KB–1MB, with 16.7 million colors and real 8-bit transparency. There's no technical argument for choosing GIF over WebP in 2026. The only question is whether your platform accepts WebP uploads — and most do now.

Animated WebP's frame-level flexibility is a genuine technical advantage. Unlike GIF, where every frame must use the same compression method, an animated WebP can mix lossy and lossless frames. A frame with a photographic background can use lossy VP8 encoding, while a frame with sharp text overlay uses lossless VP8L — the encoder picks whichever achieves the smaller output for each individual frame.

Animated WebP is supported in Chrome, Firefox, Edge, Opera, and Safari 14+ (released September 2020). This means it's safe to use for virtually all web visitors with no fallback needed. That said, for the absolute best performance on animation, an HTML <video> element with an MP4 file is typically 10–20× smaller than an equivalent animated WebP — because MP4 uses inter-frame compression (P-frames and B-frames that reference adjacent frames), while animated WebP stores each frame independently. For important animations that matter for performance, consider MP4 in a looping muted video element.

8. WebP vs AVIF

If WebP is the current standard, AVIF is what's coming for it. Same codec lineage — WebP came from VP8, AVIF comes from AV1, which is a much more sophisticated descendant. The compression gap is real: at equivalent perceptual quality, AVIF produces files that are 20–50% smaller than WebP. For a 200KB WebP hero image, AVIF gets it down to 120–160KB. That's not a marginal improvement.

AVIF's technical advantages go beyond compression ratio. It natively supports 10-bit and 12-bit color depth, enabling genuine HDR (High Dynamic Range) images with wider color gamuts including BT.2020 and DCI-P3. It supports film grain synthesis — a technique borrowed from AV1 video that encodes grain patterns as a compact filter rather than storing the actual grain pixels, which is hugely efficient for film photographs. And AVIF handles perceptual degradation at low bitrates better than WebP, because AV1's more sophisticated inter-prediction tools were adapted for intra-frame encoding.

So why isn't AVIF simply replacing WebP? Three reasons: encoding speed, browser support, and tooling maturity.

• Encoding speed — AVIF encoding is 3–5× slower than WebP encoding. For batch-processing thousands of images or encoding on the fly, this is a real operational constraint. WebP typically encodes in 50–200ms per image; AVIF can take 200ms–2 seconds for the same image at comparable quality.
• Browser support — WebP sits at 97%+ global support. AVIF reached approximately 94.9% global support in 2026, after Safari added full AVIF support in version 16.4 (March 2023). That ~2% gap still represents tens of millions of devices — mostly older iPhones and iPads running iOS 15 or earlier.
• Tooling maturity — WebP has been in production for 12 years. Image CDNs, optimization plugins, build tools, and CMS platforms have deeply integrated WebP support. AVIF support is still being rolled out across many of these systems, though the major players (Cloudinary, Imgix, Next.js, Cloudflare) now support it.

The recommended strategy in 2026 is to use both via the HTML <picture> element — offer AVIF to browsers that support it, with WebP as the fallback, and JPEG as the final fallback. Browsers evaluate <source> elements in order and pick the first format they can decode.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description" width="800" height="600" loading="lazy">
</picture>

This pattern delivers the smallest possible file to each browser without any JavaScript, while ensuring every user sees the image correctly.

9. Full Format Comparison Table

Before choosing a format, here's the full picture across every format you'll realistically encounter in 2026:

10. Browser Support in 2026

Browser support for WebP is now comprehensive enough that it can be treated as a baseline format, with JPEG or PNG as the fallback for the small minority of unsupported environments.

The Safari milestone in September 2020 is worth emphasizing because it was the longest holdout and the one most responsible for developers delaying WebP adoption. Apple's resistance to WebP was partly philosophical (preferring their own HEIC format, also based on a video codec) and partly competitive. When Safari 14 shipped WebP support, the calculus for web developers changed overnight — suddenly, WebP was safe to use as the default without worrying about large swaths of iPhone and Mac users seeing broken or fallback images.

11. WebP and Core Web Vitals

Here's where WebP stops being a developer preference and starts being a business decision.

Google's Core Web Vitals have been a ranking signal since 2021. Three metrics, but images mostly touch one: LCP (Largest Contentful Paint) — how long your biggest above-the-fold element takes to appear. On roughly 70% of pages, that element is a hero image. If it's slow, your LCP is slow, and your rankings feel it.

Quick reference on all three:

• LCP (Largest Contentful Paint) — Target: under 2.5 seconds. Images are the #1 cause of failures here.
• CLS (Cumulative Layout Shift) — Target: under 0.1. Images without explicit dimensions cause layout shifts.
• INP (Interaction to Next Paint) — Target: under 200ms. Less affected by images, more by JavaScript.

Switching from JPEG to WebP for your LCP hero image typically reduces file size by 30–40%. On a 4G connection at 4Mbps, that's 240ms faster for a typical hero image — often enough to move from "Needs improvement" to "Good" without touching anything else on the page.

The real-world business impact of Core Web Vitals improvements is well-documented. Rakuten 24, a major Japanese e-commerce platform, reported a 53.37% revenue increase per visitor after improving Core Web Vitals scores (Google Web.dev case study). Vodafone reported a 31% improvement in conversion rate from a 31% improvement in LCP. The correlation between page speed and revenue is consistently shown across industries.

As of 2026, only 42% of mobile web pages pass all Core Web Vitals benchmarks, according to HTTP Archive data. Image optimization — and specifically, serving images in WebP rather than JPEG or PNG — is cited by Google's own PageSpeed Insights tool as one of the most impactful single changes a developer can make. The "Serve images in next-gen formats" audit shows an estimated kilobyte savings per image, making the ROI of the migration clearly visible.

WebP also helps with CLS indirectly. The width and height attributes on <img> tags (or their equivalents in the <picture> element) allow browsers to reserve the correct space before the image loads, preventing layout shifts. When migrating to WebP, the best practice of adding explicit dimensions should always be applied simultaneously — the two improvements compound.

12. How to Convert Images to WebP

Three routes, depending on your workflow:

Using Convertlo (Free, Browser-Based)

Convertlo processes all conversions locally in your browser using WebAssembly — your files are never uploaded to a server. This means conversion is fast, private, and works offline after the initial page load.

Command Line: cwebp

Google provides the official cwebp encoder as part of the libwebp library. It's available for macOS, Linux, and Windows, and gives you precise control over every encoding parameter.

# Install on macOS (via Homebrew)
brew install webp

# Install on Ubuntu/Debian
sudo apt install webp

# Basic lossy conversion (quality 85 — recommended for photos)
cwebp -q 85 image.jpg -o image.webp

# Lossless conversion (for PNG with transparency, logos, icons)
cwebp -lossless image.png -o image.webp

# Lossless with preprocessing for better compression
cwebp -lossless -near_lossless 80 image.png -o image.webp

# Batch convert all JPGs in a directory to WebP
for f in *.jpg; do cwebp -q 85 "$f" -o "${f%.jpg}.webp"; done

# Batch convert with quality 80, resize to max 1200px wide
for f in *.jpg; do
  cwebp -q 80 -resize 1200 0 "$f" -o "${f%.jpg}.webp"
done

# Convert with metadata preservation (Exif, XMP, ICC)
cwebp -q 85 -metadata all image.jpg -o image.webp

The quality flag (-q) accepts values from 0 (smallest file, worst quality) to 100 (largest file, best quality). Quality 80–85 is the sweet spot for photographs — it achieves most of the compression benefit while preserving effectively all visible detail. For UI screenshots and text-heavy images, quality 90–95 or lossless mode may be preferable.

Photoshop, Figma, and GIMP

Photoshop CC 2022 and later supports WebP natively. To export: File → Export → Export As, then select WebP from the Format dropdown. You can adjust quality and choose between lossy and lossless. Photoshop also added WebP support in the legacy "Save for Web" dialog (File → Export → Save for Web).

Figma added WebP export in 2022. In the Export panel (right sidebar), click the + button to add an export format, then select WebP from the dropdown. You can set the quality percentage and export multiple sizes.

GIMP has supported WebP since version 2.10.2 (2018). File → Export As → change the filename extension to .webp and configure encoding options in the export dialog.

Squoosh (squoosh.app) — Google's free browser-based image encoder — is the best tool for comparing WebP quality settings side by side with the original. It shows both images simultaneously with a draggable divider, making it easy to find the lowest quality setting that's still visually acceptable for your specific image.

13. How to Use WebP in HTML

Implementing WebP in HTML is straightforward once you understand the <picture> element, which is the modern, standards-based mechanism for serving different image formats to different browsers.

The <picture> Element (Recommended Approach)

The <picture> element wraps one or more <source> elements followed by a required <img> fallback. The browser evaluates the <source> elements in order, picks the first one it can decode, and ignores the rest. If it can't decode any <source>, it falls back to the <img> element. This means older browsers — including the 3% that don't support WebP — automatically see the JPEG fallback without any JavaScript.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description" width="800" height="600" loading="lazy">
</picture>

Critical implementation notes:

• Always include the <img> fallback — it is not optional. Without it, users on unsupported browsers see a broken image.
• Always specify width and height — this allows the browser to calculate the aspect ratio before the image loads, reserving the correct space and preventing Cumulative Layout Shift (CLS). This is a Core Web Vitals requirement.
• The type attribute is required on <source> — without it, the browser can't determine the format until it downloads the file, defeating the purpose.
• Order matters — AVIF first (most efficient), then WebP, then JPEG. The browser takes the first format it supports.

Responsive WebP with srcset

For responsive images that serve different resolutions to different screen sizes, combine <picture> with srcset and sizes:

<picture>
  <source
    type="image/webp"
    srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
    sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px">
  <img
    src="image-800.jpg"
    srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
    sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
    alt="Description"
    width="1200"
    height="800"
    loading="lazy">
</picture>

This serves a 400px-wide WebP to mobile users, an 800px WebP to tablet users, and a 1200px WebP to desktop users — automatically, based on the browser's knowledge of the viewport and screen density. The JPEG srcset in the <img> element provides the same responsive behavior for browsers that don't support WebP.

LCP Hero Images: Loading Priority

For your page's LCP (Largest Contentful Paint) element — typically a hero banner or featured product photo — add loading="eager" and fetchpriority="high". These signal to the browser that this image is critical and should be fetched as early as possible, before other resources.

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img
    src="hero.jpg"
    alt="Hero image"
    width="1200"
    height="630"
    loading="eager"
    fetchpriority="high">
</picture>

Never use loading="lazy" on your LCP image — it defers loading until the element enters the viewport, which directly increases your LCP score. Only use loading="lazy" on images that are below the fold on initial page load.

14. WebP in CSS

For background images set via CSS rather than HTML, there are two approaches to serving WebP with a fallback: the modern image-set() function and the older JavaScript-class approach.

Modern: image-set()

The image-set() CSS function works similarly to the srcset attribute in HTML — you list image candidates with their types, and the browser picks the first format it supports. It is supported in all modern browsers as of 2022.

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

/* For retina/HiDPI screens, provide 2x variants */
.product-thumb {
  background-image: image-set(
    url("thumb.webp") 1x,
    url("thumb@2x.webp") 2x,
    url("thumb.jpg") 1x,
    url("thumb@2x.jpg") 2x
  );
}

Legacy Fallback: JavaScript Feature Detection

For older browsers or situations where image-set() support is uncertain, you can detect WebP support via a small JavaScript snippet and add a class to the <html> element, which CSS rules can target:

// In your JS (run early, before CSS paints)
(function() {
  var img = new Image();
  img.onload = function() {
    document.documentElement.classList.add(
      (img.width > 0 && img.height > 0) ? 'webp' : 'no-webp'
    );
  };
  img.onerror = function() {
    document.documentElement.classList.add('no-webp');
  };
  img.src = 'data:image/webp;base64,UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA';
}());

/* CSS using the html class */
.webp .hero { background-image: url("hero.webp"); }
.no-webp .hero { background-image: url("hero.jpg"); }

/* Without the class (default, for JS-disabled) */
.hero { background-image: url("hero.jpg"); }

The image-set() approach is preferred for new code — it requires no JavaScript and is increasingly well-supported. The JS class approach is a useful fallback pattern for legacy codebases.

15. WebP in WordPress

WordPress's WebP journey is a good illustration of how long it takes for a format to percolate through a mature ecosystem, even after browser support is established.

WordPress 5.8 (July 2021) was the first version to accept WebP file uploads through the media library without requiring a plugin. Before this, uploading a .webp file would trigger an error. This was a significant step, but it meant developers still had to manually upload pre-converted WebP files.

WordPress 6.1 (November 2022) went further: it began generating WebP versions of image thumbnails automatically when an image is uploaded to the media library. When you upload a JPG, WordPress now creates WebP versions of each registered thumbnail size alongside the JPEG versions. The WebP thumbnails are served to browsers that support the format.

For existing media libraries that were built before WordPress 6.1, plugins are needed to retroactively convert images. The most popular options are:

• Imagify — Automatically converts images to WebP on upload, with a bulk optimization feature for existing media. Integrates with popular caching plugins.
• ShortPixel Image Optimizer — Converts to WebP and AVIF, integrates with CDNs, and supports bulk conversion of the existing media library.
• EWWW Image Optimizer — Open-source plugin, converts to WebP and AVIF, works without an API key for local processing.

For Apache-based hosting, you can configure your server to automatically serve WebP versions of images to browsers that support them, without changing any URLs in your HTML. Add the following to your .htaccess file:

# Serve WebP to browsers that support it, if the .webp file exists
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} \.(jpe?g|png)$
  RewriteCond %{REQUEST_FILENAME}.webp -f
  RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=webp:1]
</IfModule>

<IfModule mod_headers.c>
  Header append Vary Accept env=REDIRECT_webp
</IfModule>

AddType image/webp .webp

This rewrite rule checks three conditions before serving WebP: the browser's Accept header includes image/webp, the requested file is a JPEG or PNG, and a corresponding .webp file exists in the same directory. If all three are true, the .webp file is served transparently. Browsers that don't support WebP receive the original JPEG or PNG unchanged.

16. WebP in Shopify

Shopify's CDN infrastructure — built on Fastly with Imgix for image processing — has served WebP to supported browsers automatically since 2020. When you upload any image to a Shopify store and a visitor loads the page, the CDN detects the browser's Accept header and serves WebP if it's supported — even if you uploaded a JPEG. This conversion happens transparently at the CDN edge, without any configuration on your part.

This means most Shopify merchants are already benefiting from WebP serving without knowing it. However, there are additional steps you can take to maximize the performance benefit:

• Upload native WebP files — If you upload a WebP image directly, the CDN uses it as the source for variant generation, avoiding one generation of lossy re-encoding. This is particularly important for product images that will be resized to many thumbnail sizes.
• Upload at optimal resolution — Shopify recommends uploading product images at a maximum of 2048×2048 pixels. Larger source images don't improve quality but increase storage and processing time.
• Use WebP lossless for transparent cutouts — Product images with transparent backgrounds (cutout photos) should be uploaded as lossless WebP rather than PNG, since the CDN will generate all the thumbnail variants from your source image.
• Use the correct Liquid filter — In Shopify's Liquid templating language, always use the | image_url filter (not the older | img_url filter, which is deprecated) to reference image URLs. The image_url filter works with Shopify's CDN and ensures WebP serving when supported.

<!-- Correct: uses image_url filter, enables CDN WebP serving -->
{% assign image_url = product.featured_image | image_url: width: 800 %}
<img src="{{ image_url }}" alt="{{ product.featured_image.alt }}" loading="lazy">

<!-- Deprecated: do not use img_url -->
<!-- {{ product.featured_image | img_url: '800x' }} -->

17. WebP in React / Next.js

React applications have two paths to WebP: using Next.js's built-in Image component (which handles everything automatically), or manually implementing the <picture> element pattern in plain React.

Next.js: Automatic WebP (and AVIF) Conversion

Next.js's next/image component automatically serves images in WebP (and AVIF) format to browsers that support them, with no configuration required beyond importing the component. The conversion happens on the server using the Sharp library, and the results are cached by Next.js's image optimization server.

import Image from 'next/image'

export default function ProductCard({ product }) {
  return (
    <div className="product-card">
      <Image
        src="/images/product.jpg"
        alt={product.name}
        width={800}
        height={600}
        // For LCP hero images, use priority instead of lazy loading
        priority
        // For below-fold images, omit priority (defaults to lazy)
      />
    </div>
  )
}

When this component renders, Next.js generates a URL like /_next/image?url=%2Fimages%2Fproduct.jpg&w=800&q=85. The image optimization server at that endpoint detects the browser's Accept header and serves WebP to Chrome/Firefox/Safari, or JPEG to older browsers — automatically, without any additional code from you.

Configuring AVIF + WebP in next.config.js

By default, Next.js serves WebP. To additionally enable AVIF (which is larger to encode but achieves better compression), add the formats configuration to next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    // AVIF is tried first (smaller), then WebP fallback
    formats: ['image/avif', 'image/webp'],
    // Define allowed sizes for optimization
    deviceSizes: [640, 750, 828, 1080, 1200, 1920],
    imageSizes: [16, 32, 48, 64, 96, 128, 256],
  },
}

module.exports = nextConfig

Plain React: picture Element Pattern

For React applications without Next.js, or for cases where you're managing your own image assets, a reusable OptimizedImage component built on the <picture> element is the right approach:

function OptimizedImage({ src, alt, width, height, priority = false }) {
  // Derive WebP src from original filename
  const webpSrc = src.replace(/\.(jpg|jpeg|png)$/i, '.webp')

  return (
    <picture>
      <source srcSet={webpSrc} type="image/webp" />
      <img
        src={src}
        alt={alt}
        width={width}
        height={height}
        loading={priority ? 'eager' : 'lazy'}
        fetchPriority={priority ? 'high' : 'auto'}
      />
    </picture>
  )
}

// Usage
<OptimizedImage
  src="/images/hero.jpg"
  alt="Hero image"
  width={1200}
  height={630}
  priority={true}  // Mark LCP images as priority
/>

18. When NOT to Use WebP

WebP isn't always right. Here's where it breaks — and where developers get burned without realizing it.

19. Common WebP Mistakes

These come up constantly. Even on sites that have made the switch to WebP, at least two or three of these usually slip through.

1. Forgetting the Fallback

The most common mistake: serving only WebP images without a JPEG fallback. While 97% of browsers support WebP, the 3% that don't — mostly Internet Explorer and old iOS Safari — will see broken images. Always use the <picture> element with a <img> fallback tag, and always ensure the fallback JPEG or PNG file exists on your server.

2. Using Lossy WebP for Transparent Images

Lossy WebP can create colored halos and fringing around transparent edges. If you have a product photo with a transparent cutout background, compress it with WebP lossless, not lossy — even though lossless produces a larger file. The alternative is visible quality artifacts around every edge, which will make products look unprofessional. Test any transparent WebP image against a dark and a light background before deploying.

3. Setting Quality Too Low

WebP quality 60 does not look like JPEG quality 60 — it looks considerably worse for photographs. This is because WebP's algorithm, while more efficient at the same perceptual quality level, produces different artifact types at low bitrates. Start at quality 80–85 for photographs and evaluate visually. Only reduce quality below 80 for thumbnails where fine detail isn't critical. For lossless WebP (transparency, graphics), quality settings don't apply — use the lossless flag directly.

4. Omitting width and height Attributes

An <img> tag without explicit width and height attributes (or CSS aspect-ratio) causes the browser to allocate no space for the image until it has downloaded enough of the file to know its dimensions. When the image loads, the page layout shifts — this is Cumulative Layout Shift (CLS), which penalizes your Core Web Vitals score. Always set width and height on every image element, matching the image's intrinsic pixel dimensions.

5. Using WebP for og:image

This deserves its own entry because it's easy to accidentally do when batch-converting images. If you replace the image in your <meta property="og:image"> tag with a WebP URL, your social media previews will break — Facebook, Twitter/X, LinkedIn, and other social platforms' link preview crawlers don't support WebP. Keep og:image pointing to a JPEG or PNG URL, even if the same image is served as WebP on the actual page.

20. Frequently Asked Questions