WebP: the format that does both jobs
6 Oct 2026 · Images · 7 min read
For most of the web's history, choosing an image format meant choosing a specialty. JPEG handled photographs and nothing else well. PNG handled graphics, screenshots and transparency, and produced enormous files for photographs. If you wanted the best of both, you were out of luck — until WebP arrived and quietly made the old decision obsolete for most purposes.
WebP is an image format developed by Google, first released in 2010, that does something neither of the old formats could: it compresses photographs better than JPEG and handles transparency and lossless compression like PNG. A decade and a half later, with universal browser support, it is the default sensible choice for web images. This article explains what it is, how big the advantage really is, and — because no format is perfect — where you should still think twice.
What WebP actually is
WebP's lossy compression is derived from the VP8 video codec — the same family of technology that compresses YouTube videos. That heritage matters, because video codecs spent decades getting extremely good at one specific thing: describing images with as few bits as possible by predicting each block of pixels from its neighbours and encoding only the difference. Applied to still images, those techniques beat JPEG's older approach by a comfortable margin.
Crucially, WebP is not one trick but three in a single container. It has a lossy mode for photographs (the JPEG replacement), a lossless mode for graphics (the PNG replacement), and full alpha-channel transparency in both. It even supports animation, making it a credible replacement for animated GIFs at a fraction of the file size. One format genuinely covers the jobs that used to need two or three.
How big is the advantage, really?
Google's published figures — broadly confirmed by independent testing over the years — put WebP's lossy mode at roughly 25–35% smaller than JPEG at equivalent visual quality, and its lossless mode at roughly 26% smaller than PNG. Here is what that looks like for a typical 12-megapixel daylight photo:
| Format and setting | File size | Notes |
|---|---|---|
| JPEG, quality 80 | ~1.6 MB | The baseline everyone knows. |
| WebP, quality 80 | ~1.05–1.15 MB | Visually equivalent, roughly a third smaller. |
| PNG (lossless photo) | ~11 MB | Impractical for photos; shown for scale. |
| WebP lossless (photo) | ~8 MB | Still impractical for photos — lossless is for graphics. |
| PNG (logo with flat colours) | ~180 KB | Typical for a detailed logo. |
| WebP lossless (same logo) | ~120–135 KB | Same pixels, about a quarter smaller. |
Two things stand out. First, the lossy advantage is large enough to matter at scale: a site serving a million photo views a day saves real bandwidth and real loading time. Second, the lossless advantage is real but smaller in absolute terms — tens of kilobytes rather than megabytes — because lossless files were already reasonably efficient for simple graphics.
There is a newer format, AVIF, that compresses better still — often 30–50% smaller than JPEG. But AVIF encoding is dramatically slower, support in editing tools is spottier, and for most everyday purposes WebP's advantage is already most of the available win with none of the friction. WebP is the pragmatic choice; AVIF is the enthusiast's choice.
WebP vs AVIF: should you skip ahead?
Since AVIF keeps coming up, here's the honest comparison. AVIF is based on the AV1 video codec — a generation newer than WebP's VP8 roots — and on pure compression efficiency it wins clearly: expect files 20–30% smaller than WebP at the same visual quality, with particularly impressive results on high-detail photographs and HDR content.
So why isn't this article recommending AVIF instead? Three practical reasons. First, encoding speed: AVIF encoding can be ten to fifty times slower than WebP depending on settings, which matters the moment you're processing more than a handful of images. Second, tooling: while browsers support AVIF widely now, everyday editors, CMS plugins and social platforms handle WebP more consistently — fewer "why won't this upload" surprises. Third, diminishing returns: if WebP already cut your JPEG in half, AVIF shaving another quarter off that is a smaller absolute win for considerably more friction.
The sensible posture in 2026: use WebP as your default, and reach for AVIF for the specific images where bandwidth matters most — hero images on high-traffic pages, for example — ideally served with a WebP fallback for older pipelines. Revisit the balance yearly; AVIF's tooling is improving fast, and the answer may change.
Where it works in 2026
The historical objection to WebP was browser support. That objection has expired. Every current version of Chrome, Edge, Firefox and Safari — desktop and mobile — displays WebP natively, and has for years. For all practical purposes, if someone's browser can load your website, it can display your WebP images.
Support beyond browsers is nearly as good. Major image editors, content management systems and social platforms accept WebP uploads. Android has supported it since version 4.0, iOS since 14. The format has crossed from "new and risky" to "boring infrastructure," which is exactly what you want from a file format.
One practical note on platforms: several social networks and messaging apps accept WebP uploads but silently convert them to JPEG on their servers — which means your carefully compressed WebP gets recompressed, with generation loss, before anyone sees it. For images destined for social sharing, this is worth knowing: the file your audience sees is the platform's recompressed version, not yours. Upload the highest quality you can within their limits and let their pipeline do its worst to a good source, rather than pre-compressing aggressively yourself.
When to still avoid it
Universal browser support does not mean universal everything. Here are the situations where WebP is still the wrong call:
- Email newsletters. Some email clients — particularly older versions of Outlook, which a meaningful slice of corporate inboxes still uses — do not render WebP. For email, JPEG and PNG remain the safe choices, because an image that doesn't display is infinitely worse than one that's slightly larger.
- Archival masters. For the one copy you keep forever, longevity of tooling matters more than file size. JPEG and PNG have three decades of universal support behind them; WebP has one and a half. Keep masters in the boring formats.
- Recipients you can't control. If you're sending images to a print shop, a client, or a government form, use what they ask for — which will be JPEG, PNG or TIFF. Compatibility beats efficiency when someone else's software is in the loop.
- Very old devices. If your audience includes a meaningful share of decade-old phones or embedded systems, the old formats are safer. This is increasingly rare, but check your analytics before assuming.
- Encoding speed at scale. WebP encoding is slower than JPEG encoding — noticeably so at high quality settings. For real-time pipelines processing thousands of images a minute, that CPU cost is worth measuring.
The honest caveat
WebP is lossy-or-lossless per file, and the two modes have the same sharp edges as the formats they replace. WebP lossy at low quality settings produces its own flavour of artefacts — smudged rather than blocky, but artefacts all the same — and generation loss applies exactly as it does to JPEG: recompressing a lossy WebP compounds the damage. And one practical annoyance: because WebP files are less familiar, some desktop software still opens them with the wrong application or refuses to preview them, which surprises people even in 2026. The format won the web; it hasn't fully won the desktop.
The pragmatic rule: use WebP (lossy, quality 75–85) for photographs on the web, WebP lossless for graphics with transparency, and keep JPEG/PNG for email, archives and anyone whose software you don't control. That covers roughly 95% of real decisions, and the remaining 5% are edge cases you'll recognise when you meet them.