Updated: June 25, 2026
For most modern websites, WebP is the better delivery format: it typically produces files roughly 25–34% smaller than JPEG at similar visual quality, supports transparency and animation in a single file, and is now supported by the vast majority of browsers worldwide — including every major engine since Safari 14 shipped in 2020. A practical 2026 workflow is to keep high-quality JPEG, PNG, or TIFF originals as your source of truth, serve WebP to modern browsers, and keep a JPEG fallback wherever your audience or channel needs it. JPEG still matters as the universal interchange format for email, print, long-term archives, and maximum-compatibility pipelines. If you want the absolute smallest files and can accept the encoding overhead, AVIF can compress further than WebP — but its performance advantage varies by image type and device, so test before deploying widely.
Key Takeaways
- WebP is 25–34% smaller than JPEG at equal quality — based on Google's own SSIM benchmarks — and roughly 26% smaller than PNG for lossless images.
- WebP browser support is well above 95% globally in 2026 (Can I Use, mid-2026), covering Chrome, Firefox, Safari, Edge, and Samsung Internet.
- JPEG remains the right call for email, print, long-term archives, and maximum compatibility, because WebP may fail or be unsupported in those pipelines.
- WebP does four jobs in one format: lossy, lossless, transparency (alpha), and animation — replacing JPEG, PNG, and GIF for web delivery.
- Keep JPEG as your source format, serve WebP as your delivery format. Never overwrite originals with WebP.
- AVIF can compress further than WebP, especially on photos and gradients, but encoding/decoding overhead and support should be verified on your traffic before committing.
WebP vs JPEG: Side-by-Side Comparison
| Feature | WebP | JPEG |
|---|---|---|
| Lossy file size vs JPEG at equal quality | ~25–34% smaller | Baseline |
| Lossless compression | Yes | No |
| Transparency (alpha channel) | Yes, even in lossy mode | No |
| Animation | Yes (replaces GIF) | No |
| Browser support (2026) | 95%+ globally | ~100% |
| Decode speed | Fast | Fastest |
| Color depth | 8-bit per channel | 8-bit per channel |
| Email-client support | May fail (Outlook desktop, some older clients) | Excellent |
| Print-service support | Often not accepted | Excellent |
| Best primary use | Web delivery, hero/LCP images, product photos | Archives, email, print, max compatibility |
The core conclusion: WebP is the better delivery format for modern web browsers; JPEG remains the universal master and interchange format. Most production pipelines end up using both.
How Much Smaller Is WebP Than JPEG?
Google's compression study — the most-cited benchmark in this space — measured file sizes at an equivalent Structural Similarity (SSIM) index, a perceptual quality metric calibrated to what the human eye actually sees. At that equal-quality threshold, WebP produces files roughly 25–34% smaller than JPEG. For lossless images, WebP is approximately 26% smaller than PNG.
Source: WebP Compression Study — Google for Developers and An image format for the Web.
To put these numbers in practical terms, based on the Google benchmark range:
| Image scenario | Estimated JPEG size | Estimated WebP size | Approximate saving |
|---|---|---|---|
| Hero / banner photo | 220 KB | ~150–165 KB | ~25–32% |
| Product photo (single) | 80 KB | ~55–60 KB | ~25–32% |
| Gallery grid (12 images) | 960 KB | ~650–720 KB | ~25–32% |
These are illustrative estimates derived from Google's 25–34% compression range, not individually measured test results. Your actual savings will vary by image content, quality setting, and encoding tool.
That reduction directly lowers Largest Contentful Paint (LCP) time and total page weight, which is why Google's web performance guidance lists "serve images in next-gen formats" as a concrete optimization opportunity.
Image Quality at the Same File Size
If you hold file size constant rather than quality, WebP delivers noticeably better images — sharper edges, cleaner text, and fewer blocky artifacts in gradients, skies, and skin tones. JPEG's DCT-based compression tends to introduce ringing and banding at aggressive settings; WebP's predictive coding handles smooth regions more gracefully.
One honest caveat: at very low bitrates, WebP can occasionally produce a slight "smoothing" effect. At normal web-delivery quality settings (WebP quality 75–85), this is rarely visible and is almost always a better trade-off than JPEG block artifacts. If pixel-level fidelity matters more than byte count — for example, a portfolio print preview — keep the original JPEG or TIFF as your display master and only compress a web-display copy.
Is WebP Browser Support Good Enough in 2026?
This used to be WebP's weak point. It is not anymore.
Can I Use reports WebP global support well above 95% as of mid-2026, with every major browser engine fully on board:
| Browser | First full WebP support |
|---|---|
| Chrome | v23 (2012) |
| Opera | v12.1 (2012) |
| Edge | v18 (2018) |
| Firefox | v65 (2019) |
| Safari (macOS + iOS) | v14 (2020) |
| Samsung Internet | v4.0 (2016) |
| Internet Explorer 11 | Never |
Source: Can I Use — WebP.
Safari 14 in September 2020 was the turning point. Before it shipped, a significant share of web traffic could not render WebP. After it, global support climbed steadily as old Safari versions and Internet Explorer retired from active use.
Gaps still exist. WebP may fail or produce unexpected results in:
- Email clients — Outlook desktop (Word rendering engine) and some older mail clients may not render WebP. This is the single most common reason to keep a JPEG version. For precise client-by-client data, see Can I Email.
- Print services and design handoff — many print shops and professional print pipelines often require JPEG, PNG, or TIFF. Check your specific service's upload documentation before assuming WebP is accepted.
- Some social-media upload surfaces — while most platforms accept WebP for post images, some profile photos, cover images, or marketplace listings may still prefer JPEG. Check each platform's current upload requirements.
- Legacy embedded browsers — older smart TVs, e-readers, kiosks, and corporate IE11 deployments.
For a public website targeting modern browsers, the compatibility risk is very low. For an email newsletter, a print catalog, or a government/kiosk context, JPEG is the safer choice.
WebP as Delivery Format, JPEG as Source: The Safest Workflow
The most durable production pattern is to treat each format as doing a different job:
| Role | Recommended format(s) | Why |
|---|---|---|
| Source / master | JPEG, PNG, or TIFF | Universal editability, lossless archiving, accepted everywhere |
| Web delivery | WebP (primary), AVIF (enhancement) | Smallest payload for modern browsers |
| Compatibility fallback | JPEG | Works in email, print, legacy browsers, and social platforms |
Keep originals at high quality, generate WebP (and optionally AVIF) derivatives for delivery, and serve them with the HTML <picture> element. Never overwrite an original with a WebP copy.
When WebP Is the Better Choice
Pick WebP when the destination is a modern web browser:
- Hero and LCP images — a smaller payload speeds up the metric Google weighs most heavily in Core Web Vitals.
- E-commerce product photos and galleries — many images × 25–34% savings = a much lighter page.
- Images that need transparency — lossy WebP with an alpha channel replaces heavier PNGs.
- Short animations — animated WebP replaces bloated GIFs at a fraction of the size.
- CMS-driven blogs and content sites — most modern platforms generate WebP automatically on upload.
In all of these cases, quality is equal or better, bytes are fewer, and compatibility risk is negligible for current browsers.
When JPEG Still Wins
JPEG is not obsolete — it is the universal interchange format. Use it when compatibility or editability matters more than byte savings:
- Email marketing — newsletters and transactional email should use JPEG (or PNG), as WebP may fail for some recipients. Verify support with Can I Email before switching.
- Print and physical products — any workflow that ends on paper, signage, or merchandise typically requires JPEG or TIFF.
- Long-term master archives — JPEG is universally decodable and is what most editing, DAM, and backup tools expect.
- User-uploaded originals — accept JPEG as the source, then generate WebP derivatives for display.
- Maximum-compatibility public surfaces — government, healthcare, kiosk, or accessibility-critical sites where you cannot assume a modern browser.
- Social-media profile and cover images — check each platform's upload requirements, as some still prefer or require JPEG.
A healthy pipeline uses both: JPEG for storage and compatibility, WebP for web delivery.
What About AVIF and JPEG XL?
WebP is not the end of the road. Two newer formats are worth knowing:
-
AVIF — built on the AV1 video codec, AVIF often compresses smaller than WebP, particularly for photographic content, gradients, and smooth color regions. The trade-off is that encoding and decoding cost can be higher, which may affect performance on lower-end mobile devices — though tooling has improved significantly since 2023. Browser support is strong but slightly below WebP. Test AVIF compression and decode time on representative images and your audience's target devices before rolling it out widely.
Reference: AVIF updates 2023 — web.dev and Image formats — MDN.
-
JPEG XL — offers strong mathematical compression and can losslessly recompress existing JPEGs. Browser support remains inconsistent across major engines, making it a format to watch rather than deploy at scale today.
For 2026, the pragmatic delivery stack is AVIF → WebP → JPEG, served in preference order via the <picture> element. Most sites get the full benefit from WebP alone; layering AVIF on top adds further savings for the browsers that support it.
Should I Convert Every JPEG on My Site to WebP?
No — prioritize strategically:
- Start with high-impact pages: homepage heroes, product listing pages, and any page where images are the largest element and drive LCP.
- Focus on large images first: a 400 KB product photo saves far more bytes than a 5 KB icon.
- Skip images already tiny or already optimized: very small images have diminishing returns from format conversion.
- Leave archives, email templates, and print assets as JPEG: converting those would break existing workflows.
- Add AVIF as an enhancement layer: once WebP is in place, test AVIF selectively on your highest-traffic image-heavy pages.
How to Switch From JPEG to WebP
The migration is low-risk because you never delete the original. Here is the full workflow.
Step 1 — Keep a high-quality master. Store an uncompressed or lightly compressed JPEG (or PNG/TIFF) original. This is your edit and print source; you will never overwrite it.
Step 2 — Compress and convert to WebP. Resize the image to the largest display size you need, then export a WebP at quality 75–85 for photos. Before uploading images, you can use a tool such as LessMB to reduce image file size; verify the output format, dimensions, and visual quality before replacing production assets. For automated pipelines, the official cwebp tool or build-step integrations (Vite, Next.js next/image, Sharp) generate WebP copies as part of your build.
Step 3 — Set layout attributes to prevent CLS. Always include explicit width and height (or aspect-ratio in CSS) so the browser reserves space and your Cumulative Layout Shift stays in the green.
Step 4 — Serve both formats with <picture>. Let the browser pick the best option it supports:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Descriptive alt text" width="1200" height="800" loading="lazy">
</picture>
Step 5 — Optimize the LCP image specifically. For the single image that drives LCP, drop loading="lazy" and add fetchpriority="high" so the browser fetches it first:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="..." width="1200" height="800" fetchpriority="high">
</picture>
Reference: Optimize LCP — web.dev and fetchpriority — Chrome for Developers.
Step 6 — Compress everything else. Below-the-fold images keep loading="lazy" and decoding="async" to avoid blocking the main thread.
How to Verify Your Images Are Actually Optimized
Switching formats only helps if it is verified in production. Run this checklist before and after your migration:
| Check | Tool | What to look for |
|---|---|---|
| Format actually served | DevTools → Network → Img filter | .webp or .avif in response, not .jpg |
| File size reduction | Network tab — compare transfer sizes | Smaller than pre-migration baseline |
| LCP impact | Lighthouse Performance audit | Lower LCP estimate; "Serve next-gen formats" no longer flagged |
| Field data improvement | PageSpeed Insights | LCP improves in real-user (CrUX) data |
| Fallback rendering | BrowserStack or old device | JPEG fallback renders correctly, no broken images |
| CDN content negotiation | Response headers | Vary: Accept present if CDN serves format by Accept header |
Reference: Reduce image download sizes — Android Developers.
Common Mistakes to Avoid
- Deleting the JPEG original. Always keep a master; WebP is a delivery format, not an archive.
- Over-compressing to hit a byte target. Below WebP quality ~70, visible artifacts appear. Optimize for perceived quality, not the smallest possible number.
- Skipping
widthandheight. Format savings are undermined if images shift the layout and hurt your CLS score. - Serving WebP to email recipients. If the same asset is reused in a newsletter, link the JPEG, not the WebP.
- Lazy-loading the LCP image. Your hero image should load eagerly with high fetch priority, not be deferred.
- Using one giant image for all screen sizes. Pair modern formats with
srcsetresponsive sizing so mobile devices do not download a full desktop-resolution file. - Assuming AVIF always wins. AVIF's advantage varies by image content, encoder settings, and device capability. Always test before deploying widely.
FAQ
Which is better for website images, WebP or JPEG?
For most modern websites, WebP is the better delivery format. It typically produces smaller files than JPEG at similar visual quality, supports transparency and animation, and is supported by the vast majority of modern browsers. Keep JPEG for email, print, and maximum-compatibility use cases.
Does WebP reduce image quality compared to JPEG?
No. At equal perceptual quality (SSIM), WebP matches or beats JPEG while using roughly 25–34% fewer bytes. Visible quality loss only appears if you over-compress either format.
Is WebP browser support good enough in 2026?
Yes. Can I Use reports global WebP support well above 95% as of mid-2026, covering Chrome, Firefox, Safari, Edge, and Samsung Internet. The remaining gaps are mainly Internet Explorer and some legacy embedded browsers.
Should I keep a JPEG fallback for WebP?
It is optional for modern-browser-only sites but cheap insurance. The HTML <picture> element serves WebP to capable browsers and JPEG to everyone else with no extra effort, and it also covers email clients and print pipelines.
Is AVIF better than WebP?
AVIF often compresses smaller than WebP, especially for photographic or gradient-heavy images, but encoding and decoding overhead and browser support should be tested on your audience's devices. Use it as a progressive enhancement layered on top of WebP rather than a wholesale replacement.
Should I convert every JPEG on my site to WebP?
Not necessarily. Prioritize large images on high-traffic pages — heroes, product grids, galleries — where byte savings have the biggest LCP impact. Always keep original JPEGs as masters; WebP is a delivery format, not an archive format.
Is WebP better for SEO?
Indirectly, yes. WebP reduces page weight, which can lower Largest Contentful Paint (LCP) time — a Core Web Vital that Google uses as a ranking signal. Faster pages tend to rank better and engage users more effectively.
Next Steps
- Audit your current images — run Lighthouse and note how many bytes next-gen formats would save on your highest-traffic pages.
- Pick your workflow — use a tool such as LessMB to compress images before publishing and check file size and visual quality, or automate with Sharp,
next/image, orcwebpin your build pipeline. - Convert and deploy with
<picture>— keep JPEG masters, export WebP (and test AVIF selectively), and let the browser choose the best format. - Verify in production — confirm WebP is actually served, the LCP image loads with high priority, and JPEG fallbacks render correctly on real devices.
- Make WebP export part of your publish checklist — so old habits do not creep back as new images are added.