WebP, Explained Properly: When to Use It and When Not To
13 June 2026
👉 Just need the tool? Convert to WebP — runs in your browser, nothing uploaded.
WebP does the job of both JPG and PNG. It compresses lossy or lossless, carries transparency, and animates — and it usually produces a smaller file than either format it replaces. For images going onto a website in 2026, that makes it the sensible default. For images you email, hand to a client, or open in older desktop software, it still causes friction. The format is rarely the problem. The destination is.
Here is the comparison most people are actually after:
| WebP | JPG | PNG | |
|---|---|---|---|
| Typical file size | Smallest | Small (photos) | Largest |
| Lossy compression | Yes | Yes (its only mode) | No |
| Lossless compression | Yes | No | Yes (its only mode) |
| Transparency (alpha) | Yes, full 8-bit | No | Yes, full 8-bit |
| Animation | Yes | No | No (APNG exists, support is spotty) |
| Color depth | 8-bit per channel | 8-bit per channel | Up to 16-bit per channel |
| Browser support (2026) | Effectively universal | Universal | Universal |
| Email / chat / OS preview | Decent but uneven | Universal | Universal |
| Strongest at | Web delivery — photos, graphics, and transparency in one format | Photographs anywhere | Sharp-edged graphics, screenshots, anything needing pixel-perfect fidelity |
Why one format can beat two
WebP is not a tweak on JPG; it is a different engine. Its lossy mode is built on VP8 video keyframe compression, which predicts each pixel from its neighbors and stores only the difference. That predictive approach holds detail at low bitrates better than JPG’s older block-based DCT math. Google’s own figures put a lossy WebP at roughly 25 to 34 percent smaller than a JPG of comparable quality, and that matches what you tend to see in practice. Treat it as a working expectation rather than a guarantee. Busy, grainy photos narrow the gap; flat or gradient-heavy images widen it.
Lossless WebP is a separate algorithm again, and it runs about 26 percent smaller than a comparable PNG on average (Google’s study found a density improvement across roughly 99 percent of the web images it tested). The number you actually get depends on how aggressively the source PNG was already optimized — measured against unoptimized libpng output the gap is far larger, against a heavily squeezed PNG it shrinks.
The real trick is that lossless WebP can carry an alpha channel at the same time, which is the one thing PNG was indispensable for. WebP also has a mode PNG cannot touch: lossy compression with transparency. A product shot whose soft shadow fades to nothing would be a heavyweight PNG; as a lossy WebP it can be a fraction of the size. That single capability is where the savings are often most dramatic — and it is the whole reason the format exists. One container swallows the JPG case, the PNG case, and the animated GIF case at once.
The recompression trap
This is the mistake that quietly rots image libraries, so it is worth slowing down on.
When you turn an existing JPG into a lossy WebP, you are compressing data that has already been compressed and already had detail thrown away. Lossy WebP then discards more, and it cannot tell which artifacts are genuine detail and which are JPG compression noise — so it spends bits faithfully preserving the noise. You end up with a file that is either smaller but visibly mushier, or barely smaller because the encoder fought to keep junk it should have dropped.
A few rules that keep you out of trouble:
- Convert from the original whenever you can — the camera raw, the clean PNG export, the master PSD. The further upstream your source, the better the result.
- If your only source is a lossy JPG, reach for lossless WebP or a high lossy quality (85 and up). Running a quality-60 JPG through quality-60 WebP and expecting magic is how you get the mushy result above.
- Never re-save the same lossy WebP again and again. Each pass loses a little more, like photocopying a photocopy. Keep a lossless master and re-export from it.
The caution runs both directions. Converting a lossy WebP back to JPG recovers nothing the WebP already discarded. There is no undo for a lossy step.
What support actually looks like in 2026
In the browser, WebP is a non-issue. Every current version of Chrome, Edge, Firefox, and Safari decodes it, and has for years — Safari was the last holdout and added it in version 14, back in September 2020. If your visitors are on a browser from the last several years, you can serve WebP directly. The old <picture> fallback to JPG is now mostly belt-and-suspenders: worth keeping for a long-tail audience, optional for everyone else.
Outside the browser, it gets patchier, and this is where people get caught out:
- OS previews and file managers generally handle WebP now on current Windows, macOS, and most Linux desktops. Old or locked-down machines may still show a broken thumbnail.
- Email and chat apps are inconsistent. Some render WebP inline, some show it as an unknown attachment, some silently convert it. If you are sending an image to a person rather than publishing it, JPG or PNG is the safer courtesy.
- Design and office software is the real gap. Plenty of older Photoshop, Office, and line-of-business tools will not import WebP without a plugin. Print workflows in particular tend to reject it outright.
- Some platforms re-encode on upload. Social networks, CMSes, and marketplaces routinely transcode whatever you give them, so uploading WebP may gain you nothing and can occasionally cost quality.
All of this shifts as apps update, so check against the specific tool or recipient that matters to you rather than trusting a blanket “everything supports it now.” The browser story is settled. The everything-else story is not.
Reach for WebP when
- You are putting images on a website or web app and you control the markup. This is the easy yes — smaller pages, faster loads, no real downside.
- You need transparency and a small file at the same time, especially for photographic or shadowed content where a PNG would balloon.
- You want one format across a mixed asset set — photos, logos, icons — instead of juggling JPG and PNG.
- You are replacing animated GIFs. WebP animation is far more efficient and supports millions of colors rather than GIF’s 256-color cap.
Skip WebP when
- You are emailing or messaging an image to a person, or handing a file to someone whose software you cannot see. Use JPG for photos, PNG for graphics.
- The work is headed for print, or into older design and office tools that may not read it.
- You need maximum fidelity or high bit depth — archival masters, medical imaging, anything beyond 8 bits per channel, which WebP cannot store. Keep the master in PNG or TIFF and treat WebP as a delivery copy, never the archive.
- The destination re-encodes on upload anyway. Hand it your highest-quality source and let it do its own thing.
Where it sits now
WebP is the dependable, broadly supported choice for the web, and it is no longer the new arrival. AVIF often compresses smaller, and JPEG XL keeps circling for wider adoption, but WebP’s support is more uniform and its tooling more mature than either. If you want one format that works everywhere a browser runs and meaningfully trims your page weight, it is hard to argue against.
The framing that keeps you out of trouble: WebP is a delivery format, not a master format. Keep your originals, convert from them, and pick the output to fit where the image is actually going.
When that destination is the web, you can convert to WebP right in the browser — nothing uploads, the files never leave your machine — and the same goes for the rest of our free tools when you need to go the other way for an email or a print job.