Guide

When WebP makes sense for website images

WebP is useful when modern browser delivery, page weight, and bandwidth efficiency matter. This guide covers browser support, migration strategies, size comparisons, CDN compatibility, and fallback approaches for legacy environments.

Overview

Why WebP matters for web publishing

WebP offers better compression, smaller files, and feature parity with both JPG and PNG, making it the ideal format for modern web delivery.

The web performance problem

Images are typically the largest contributor to page weight on modern websites, often accounting for 60% to 80% of total bytes downloaded. Large image files slow down page loads, increase bounce rates on mobile networks, consume user data allowances, and reduce search engine rankings because Core Web Vitals metrics like Largest Contentful Paint are heavily influenced by image loading speed. For publishers, e-commerce sites, blogs, and marketing landing pages, reducing image weight without degrading visual quality is one of the highest-impact optimizations available. WebP addresses this problem by delivering the same visual quality as JPG and PNG at significantly smaller file sizes, which translates directly into faster page loads, lower bandwidth costs, and better user experience across all devices and network conditions.

WebP as a unified replacement

Before WebP, web publishers needed two separate image formats: JPG for photographs and PNG for graphics with transparency. This meant maintaining two asset pipelines, two sets of optimization tools, and two fallback strategies. WebP unifies this by supporting both lossy compression for photographs and lossless compression for graphics, plus full alpha transparency in both modes. This means a single WebP file can replace both your JPG hero images and your PNG logos, simplifying asset management and reducing the total number of image variants that must be stored, cached, and delivered. For teams that maintain large image libraries, the simplification of having one primary web format instead of two is a significant operational benefit beyond the raw file size savings.

The case for adoption in 2024 and beyond

WebP was introduced by Google in 2010 and initially had limited browser support, which made it a risky choice for mainstream websites. However, by 2024, WebP is supported by every major browser including Chrome, Firefox, Safari, Edge, and Opera, covering over 95% of global web users. The remaining 5% consists primarily of legacy Internet Explorer versions, outdated mobile browsers, and some enterprise environments with locked-down software. For most public-facing websites, this level of support means WebP can be the primary delivery format with a simple fallback mechanism for the small minority of unsupported browsers. The technical and performance benefits are now substantial enough, and the risk small enough, that WebP adoption should be the default strategy for any new web project or image optimization initiative.

Compatibility

Browser support details and coverage

Understanding exactly which browsers support WebP and how to handle the remaining edge cases.

Modern browser support matrix

Chrome has supported WebP since version 23, released in 2012. Firefox added support in version 65, released in 2019. Safari introduced WebP support in version 14, released in 2020 alongside macOS Big Sur and iOS 14. Edge has supported WebP since its Chromium-based relaunch in 2020. Opera has supported WebP since version 12.10. This means every modern browser on desktop and mobile can render WebP images natively. The global usage share of these supported browsers exceeds 95% according to Can I Use and StatCounter data. For context, this is a higher support level than many CSS features that developers use without hesitation, such as Flexbox or CSS Grid in their earliest forms. WebP is no longer an experimental format; it is a mainstream web standard.

Remaining unsupported environments

The primary unsupported environment is Internet Explorer 11 and earlier versions, which have a small but non-zero usage share in enterprise and government sectors. Some older Android browsers based on WebKit versions before 2014 also lack WebP support. Certain email clients, including some versions of Outlook and Apple Mail, do not render WebP images in email bodies, which means marketing emails should still use JPG for images. A small number of native mobile applications with embedded web views may use outdated rendering engines that do not support WebP. For most consumer-facing websites, the unsupported audience is small enough that a simple fallback mechanism is sufficient. For enterprise or government sites with a known IE11 user base, the fallback strategy becomes more important, but even in those cases, WebP can be deployed with a JPG fallback that serves the older format only to unsupported browsers.

Detecting WebP support programmatically

Modern web development provides several ways to serve WebP conditionally. The HTML picture element allows you to specify multiple source formats, with the browser loading the first one it supports. The CSS image-set function lets you define background images with multiple format options. Server-side content negotiation can inspect the Accept header and serve WebP to browsers that declare support. JavaScript feature detection using a small test image can determine support dynamically for lazy-loaded content. Content Delivery Networks like Cloudflare and CloudFront can automatically convert images to WebP at the edge based on the requesting browser's capabilities. The key point is that you do not need to choose between WebP and a fallback; you can serve both and let the browser or the CDN select the appropriate format automatically.

Performance

File size comparison and visual quality analysis

WebP consistently produces smaller files than JPG and PNG at equivalent visual quality across diverse content types.

WebP vs JPG for photographs

For photographic content, WebP lossy mode typically produces files that are 25% to 35% smaller than equivalent-quality JPG files. At quality 80, a 1920x1080 photograph might be 350 KB as JPG and 240 KB as WebP, a reduction of over 30%. At lower quality settings, the gap can widen further because WebP's prediction model and entropy coding are more efficient than JPG's older Huffman-based system. The visual quality at equivalent file sizes is also better: a WebP at 200 KB typically shows less blockiness and fewer chroma artifacts than a JPG at 200 KB. For publishers who serve hundreds or thousands of images per page, such as news sites and e-commerce catalogs, a 30% reduction in image weight translates directly into faster Largest Contentful Paint scores, lower data transfer costs, and improved mobile user experience.

WebP vs PNG for graphics and transparency

For lossless graphics and transparent images, WebP lossless mode typically produces files 20% to 30% smaller than PNG. For a simple logo with transparency, a PNG might be 45 KB while the WebP equivalent is 30 KB. For a complex screenshot with many colors, a PNG might be 800 KB while the WebP lossless version is 550 KB. The visual quality is identical because both formats are lossless. The advantage of WebP is purely file size. For transparent graphics, WebP also supports lossy compression with alpha, which can produce dramatically smaller files than PNG while maintaining acceptable transparency quality. A transparent PNG of a photographic cutout might be 2 MB, while a lossy WebP with alpha at quality 80 could be 300 KB, an 85% reduction with minimal visual degradation. This makes WebP particularly compelling for e-commerce product images with transparent backgrounds and for UI elements that need to overlay variable backgrounds.

Quality settings and perceptual equivalence

When comparing formats, it is important to match perceptual quality rather than numeric quality settings. A WebP at quality 75 is typically visually equivalent to a JPG at quality 85, because WebP's encoding pipeline preserves more detail at lower numeric settings. When migrating from JPG to WebP, a good rule of thumb is to start with WebP quality 75–80 for photographs and compare the visual result to your existing JPG at quality 85. For lossless graphics, no quality slider is needed because both PNG and WebP lossless are bit-perfect. For lossy transparent graphics, start with quality 80 and inspect the edges of the transparent regions at the target display size. If the edges look acceptable, the file size savings will usually be substantial. Always test on actual content rather than relying on generic benchmarks, because the savings vary with image complexity, color distribution, and the presence of fine detail.

Strategy

Migration strategy for existing websites

Transitioning an existing image library to WebP requires planning, tooling, and a phased approach that minimizes disruption.

Phase 1: Audit and benchmark

The first step in any migration is to understand the current state. Audit your existing image assets to identify which are JPG, which are PNG, and which are already WebP or other formats. Measure the total image weight across your most important pages, such as the homepage, product listing pages, and article pages. Use tools like Lighthouse, WebPageTest, or your browser's DevTools Network panel to establish baseline performance metrics including Largest Contentful Paint, total image bytes, and the number of image requests. Identify your most impactful images, typically the largest files and the most frequently loaded pages, because optimizing these will yield the biggest performance improvements. This audit gives you a before-and-after measurement framework and helps prioritize which assets to convert first.

Phase 2: Convert high-impact assets

Start the conversion with your highest-impact images: hero banners, product photos, category images, and article featured images. Use batch conversion tools or command-line utilities like cwebp to convert these files to WebP at the appropriate quality settings. For each converted image, compare the visual quality to the original at the target display size. Do not compare at 100% zoom on a 4K monitor unless that is how your users will view the image; compare at the actual rendered size on a typical device. Document the file size savings for each image type so you can report the aggregate impact. If you are using a static site generator or content management system, update the image references to point to the WebP versions or use the picture element to serve WebP with a fallback.

Phase 3: Implement fallback and automated delivery

Once your high-impact assets are converted, implement the fallback strategy so that unsupported browsers still receive a functional image. The two most common approaches are: using the HTML picture element with source srcset for WebP and a fallback img tag for JPG or PNG, or using a CDN that automatically converts images to the optimal format based on the Accept header. The picture element approach is simple and requires no server-side changes, but it does require updating your HTML templates. The CDN approach is more scalable because it handles conversion automatically for all images without template changes, but it may incur additional CDN costs and can introduce a small latency overhead. For most sites, a CDN with automatic image optimization is the best long-term solution, while the picture element is a good immediate fallback for critical images during the transition period.

Phase 4: Update build pipelines and workflows

After the initial migration, update your image processing pipeline so that new assets are generated in WebP by default. If you use a static site generator, add a WebP conversion step to your build process. If you use a content management system, configure it to generate WebP variants alongside the original uploads. If you have a design team, update their export guidelines to include WebP as the primary web format. Train content editors and marketers to upload high-quality originals and let the pipeline generate the optimized WebP variants rather than uploading pre-compressed images. This prevents the quality degradation that occurs when editors manually compress images in desktop tools before upload. The goal is to make WebP the default and automatic choice, not a manual extra step that gets forgotten.

Infrastructure

CDN compatibility and edge optimization

Content Delivery Networks can automate WebP conversion, caching, and format negotiation at the edge.

Cloudflare Polish and image optimization

Cloudflare offers an image optimization feature called Polish that can automatically convert JPG and PNG images to WebP at the edge when the requesting browser supports it. This means you can keep your origin server serving traditional formats while Cloudflare transparently serves WebP to modern browsers. Polish also supports lossless compression for PNG and auto-compression for JPG, which can reduce file sizes even for browsers that do not support WebP. The configuration is straightforward: enable Polish in the Cloudflare dashboard, select the desired optimization level, and the CDN handles the rest. This is an excellent option for sites that want WebP benefits without changing their origin image files or HTML templates. The trade-off is that Polish is a paid feature on some Cloudflare plans, and the edge conversion adds a small amount of processing time on the first request for each image.

AWS CloudFront and Lambda@Edge

Amazon CloudFront does not have built-in WebP conversion like Cloudflare Polish, but you can implement it using Lambda@Edge functions that inspect the Accept header and convert images on the fly. Alternatively, you can use AWS Elemental MediaConvert or pre-process your images into multiple formats before uploading to S3. Another approach is to use Amazon's CloudFront Functions to route requests to different S3 buckets or paths based on the Accept header, serving a pre-generated WebP file when available and falling back to the original JPG or PNG when not. This requires more setup than Cloudflare Polish but offers greater control over the conversion quality, caching rules, and cost structure. For teams already invested in the AWS ecosystem, this approach integrates well with existing S3, CloudFront, and Lambda workflows.

Other CDN and hosting platforms

Many modern hosting platforms and CDNs offer automatic WebP conversion. Vercel and Netlify both support automatic image optimization with WebP conversion for images served through their asset pipelines. ImageKit, Imgix, and Cloudinary are specialized image CDNs that offer real-time format conversion, responsive resizing, and automatic WebP delivery based on browser support. WordPress users can install plugins like WebP Express or ShortPixel that generate WebP variants and serve them with fallback mechanisms. These platforms handle the complexity of format negotiation, caching, and fallback generation, making WebP adoption accessible even for teams without dedicated DevOps resources. The general trend across the hosting and CDN industry is toward automatic image optimization, which means WebP support is becoming the default rather than a special configuration.

Compatibility

Fallback strategies for legacy browsers and systems

A robust WebP deployment includes a fallback plan so that no user sees a broken image.

The picture element with multiple sources

The HTML5 picture element is the standard way to provide WebP with a fallback. Inside a picture element, you specify one or more source elements with type attributes indicating the image format, followed by a standard img element that serves as the fallback. The browser loads the first source whose type matches a supported format, and if none match, it falls back to the img element. For example, you can specify a source with type image/webp and a srcset pointing to the WebP file, followed by an img element pointing to the JPG or PNG file. This approach works in all modern browsers and degrades gracefully to the fallback image in older browsers. The picture element also supports media queries, which means you can combine format fallback with responsive art direction, serving different image crops for different screen sizes while still using WebP as the primary format.

Server-side content negotiation

Server-side fallback uses the HTTP Accept header to determine which formats the browser supports. When a browser requests an image, it sends an Accept header that may include image/webp if WebP is supported. Your server or CDN can inspect this header and serve the WebP version if supported, or the JPG or PNG version if not. This approach keeps your HTML clean because you only reference a single image URL, and the server handles the format selection transparently. Apache and Nginx can be configured to do this with rewrite rules based on the Accept header. Some CDNs, including Cloudflare and Fastly, support this behavior natively or through custom VCL configurations. The downside is that it requires server-side configuration and careful cache management, because caching layers must vary the cache key by the Accept header to prevent serving WebP to unsupported browsers from a shared cache.

JavaScript detection and lazy loading

For sites that use JavaScript-based lazy loading or image galleries, you can detect WebP support programmatically and set the image source accordingly. The standard detection technique creates a small WebP image in memory, attempts to decode it, and checks whether the browser reports a valid width and height. This detection can run once per page load and store the result in a variable or cookie, which subsequent image loading logic can reference. If WebP is supported, the lazy loader requests the WebP version of each image. If not, it requests the JPG or PNG version. This approach integrates well with modern JavaScript frameworks and lazy loading libraries, and it avoids the need to modify HTML markup for every image. The trade-off is that it requires JavaScript to run before images load, which can delay the initial image requests slightly and may not work for users with JavaScript disabled.

Email and non-web environments

Email clients are the most important non-web environment where WebP fallback matters. Most email clients, including Outlook, Apple Mail, and Gmail, do not reliably support WebP images in email bodies. For marketing emails, newsletters, and transactional email templates, continue to use JPG for photographs and PNG for graphics with transparency. Do not attempt to use WebP in email unless you are targeting a very narrow audience with known WebP support. Similarly, some native mobile applications, desktop software, and document editors do not support WebP. If your images are used in PDF generation, print workflows, or native app embedding, keep JPG and PNG as the primary formats and use WebP only for the web-specific delivery pipeline. The principle is to match the format to the environment: WebP for web browsers, JPG and PNG for everything else.

Strategy

Use WebP for delivery, not archive

Keep originals in a safer format for editing and long-term storage.

Delivery format vs. working format

WebP is designed for smaller web delivery. It is not the best format for long-term storage or repeated editing. Keep your originals in JPG, PNG, or a raw format. Export to WebP only when you publish the image to a website or web app. If you need to edit the image again later, return to the original rather than re-editing the WebP file. The reason is that WebP, while efficient, is not as universally supported by desktop editing tools as JPG and PNG. Some versions of Photoshop, GIMP, and other editors require plugins to open WebP, and color space handling can vary between tools. By keeping your master files in a widely supported format and generating WebP copies only for the delivery stage, you preserve the flexibility to re-edit, re-export, and re-optimize without being locked into a format that your editing tools may not handle perfectly.

Quality and context checking

A smaller file is only better if the image still looks acceptable in its actual context. A hero banner needs higher quality than a thumbnail. Preview the WebP export at the size it will appear on the site. If text looks blurred or gradients show banding, raise the quality or switch to a different format for that specific asset. The context of display matters enormously: an image that looks perfect at 400 pixels wide may show artifacts when displayed at 1200 pixels wide. Similarly, an image with subtle skin tones may show banding at low quality settings that would be invisible in a landscape photo. Always test your WebP exports on the actual devices and screen sizes your audience uses, not just on your development monitor. Mobile screens have different pixel densities and viewing distances, which affects the perceptibility of compression artifacts.

Next

Related guides

Continue with nearby image preparation decisions.

PNG vs JPG

A direct comparison of when to choose each format with compression algorithm analysis and real-world scenarios.