WebP, released by Google in 2010, was designed as a successor to JPG. For photographic content at equivalent visual quality, WebP files are typically 25–35% smaller — a meaningful saving on image-heavy pages where total image weight often determines Largest Contentful Paint and the broader Core Web Vitals scores.
Browser support reached effective universality with Safari 14 in 2020 — every current version of every major browser renders WebP. The remaining holdouts are email clients (Outlook desktop notably doesn't), legacy systems and some niche image-editing pipelines.
The trade-off is decode cost: WebP takes ~50% longer to decode than JPG. In practice this is invisible — browsers decode in parallel and pages are almost always bottlenecked on download time, not decode. But it's worth knowing on extremely image-dense pages on older mobile devices.
Spec comparison
| Property | WebP | JPG |
|---|---|---|
| Compression | Both | Lossy |
| Graphic type | Raster | Raster |
| Transparency | Yes | No |
| Animation | Yes | No |
| HDR | No | No |
| Embeds EXIF | Yes | Yes |
| Browser coverage | 98% | 100% |
| Introduced | 2010 | 1992 |
File size comparison
Same 1920×1280 web hero photo
WebP
WebP at q80: ~180 KB
JPG
JPG at q85: ~280 KB
WebP is about 35% smaller than JPG at visually-equivalent quality. The gap widens on larger images (more bytes to save proportionally) and narrows on tiny thumbnails (where both formats are dominated by overhead).
Quality comparison
At normal viewing sizes, WebP at quality 80 and JPG at quality 85 are visually indistinguishable. WebP handles smooth gradients (skies, skin tones) better than JPG — JPG sometimes shows visible banding in these areas at lower quality settings.
When each one wins
Use WebP if…
- You control the delivery (your website, your CDN, your app)
- File size matters — image-heavy pages, mobile-first audiences, slow connections
- You can target modern browsers (Safari 14+ for ~98% global coverage)
- You want a single format that handles photos, transparency and animation
Use JPG if…
- Email marketing — Outlook desktop doesn't render WebP
- Uploads going to platforms that re-encode anyway (Instagram, Facebook, Twitter/X)
- Workflows that integrate with image editors lacking WebP support
- Files shared with users on legacy devices or browsers
Recommendation
For any website you control, switch to WebP. Use the <picture> element to serve a JPG fallback for the rare client that can't render WebP. Migration typically delivers a 25–35% reduction in image bytes and a corresponding LCP improvement — one of the highest-impact site optimisations available.
Frequently asked questions
- Is WebP really better than JPG?
- For file size at equivalent visual quality, yes — typically 25–35% smaller. For maximum compatibility, no — Outlook desktop and a long tail of legacy systems don't render WebP. The right answer for most modern websites is to serve WebP with a JPG fallback.
- Will WebP hurt my Core Web Vitals?
- Almost always the opposite — smaller files mean faster LCP. The exception is extremely image-heavy pages on older mobile devices, where WebP's higher decode cost can outweigh the smaller download.
- Should I convert existing JPGs to WebP?
- Yes for any image that's served from a website you control. Use the website image optimiser linked below to batch-convert a whole folder. Don't convert JPGs that are already going to email or platforms that don't accept WebP.
- Why does Outlook not render WebP?
- Microsoft has been slow to add WebP to the desktop Outlook rendering engine. Outlook web and the Mac Outlook app render WebP correctly; Outlook desktop on Windows does not. For email marketing, keep using JPG.
- Does Google rank WebP better than JPG?
- Google doesn't directly rank by format. It does rank by Core Web Vitals (where smaller, faster-loading images help LCP). Switching from JPG to WebP usually delivers a small but real ranking lift on image-heavy sites.