For most of the last decade, the answer to "which image format" was JPG for photos, PNG for everything with sharp edges, and don't worry about anything else. WebP has spent that decade quietly getting good. Browser support is now universal, file sizes are visibly smaller, and the format handles both lossy and lossless. The choice has gotten harder — and worth thinking about.
The short version
- Image is for a webpage you control → WebP. Smaller, faster, browser-supported everywhere modern.
- Image is going somewhere you don't control (email, print shop, government portal, anyone's inbox) → JPG. Universal.
- You need transparency on a photographic image → WebP. JPG can't do alpha at all.
- You're not sure where it's going → JPG. Safer default.
What WebP actually is
WebP is a Google-built image format that came out of the VP8 video codec project around 2010. It supports two modes: lossy (think JPG-ish, with smaller files at equivalent quality) and lossless (think PNG-ish, but also smaller). It supports transparency in both modes. It supports animation, the way GIF does but with vastly better compression.
At equivalent visual quality, lossy WebP is typically 25–35% smaller than JPG. Lossless WebP is typically 25% smaller than PNG. On a heavy image page that's the difference between a fast site and a slow one.
What JPG still wins at
One thing: universal compatibility. JPG has been around since 1992. Every piece of software that can open an image can open a JPG. Every email client renders it inline. Every print shop accepts it. Every photo printer reads it. Every web form that takes an image accepts the .jpg extension without a fuss.
WebP can't say that. Modern browsers all support it (Chrome since 2010, Firefox since 2019, Safari since 2020, Edge since forever). But once an image leaves the browser, all bets are off. Your aunt's email client might render it. The pharmacy printer at CVS might not. The government portal that wants a passport photo definitely won't — that form was last updated in 2014.
The rule is: WebP is a web format. Once it goes anywhere else, you're rolling dice.
Quick comparison
| JPG | WebP | |
|---|---|---|
| File size (typical photo) | baseline | ~25–35% smaller |
| Lossless option | No | Yes |
| Transparency | No | Yes |
| Animation | No | Yes |
| Browser support | Universal | Universal (modern) |
| Email client support | Universal | Spotty |
| Print / portal support | Universal | Limited |
| EXIF metadata | Yes | Yes (limited) |
| Year introduced | 1992 | 2010 |
Use WebP when
The image is going on a webpage you control — your blog, your portfolio, your app, your e-commerce product images. The visitors are using modern browsers (essentially anyone, at this point). Page weight matters. You care about Core Web Vitals or just don't want to ship 4 MB hero images.
You need transparency on a photograph. JPG can't do this, full stop. PNG can, but a transparent PNG of a photograph is huge. WebP gives you a transparent photographic image at roughly the JPG file size.
You're building a static site, generating thumbnails at build time, or running images through a CDN that can serve WebP to capable browsers and fall back to JPG for the rest. Modern image CDNs do this automatically.
Use JPG when
The image is going in an email. Email clients are a fragmented mess and "supports WebP inline" is not safe to assume — some show a broken-image icon, some show nothing.
The image is going to a print shop or a photo printer. Most printer drivers and photo kiosks are years behind.
The image is being uploaded to a portal — government, healthcare, education, anything regulated, anything legacy. The upload widget will reject the extension or accept it and fail silently downstream.
You're sending it to a person who'll save and reuse it. Once it's a WebP on their drive, every downstream tool that touches it has to handle WebP, and most of them won't.
Anything print-bound. Printers want a known quantity.
Converting between them
Both directions work, and we have a converter for each:
- JPG → WebP — typical use case, shrinking existing JPG assets for the web.
- PNG → WebP — same shrink, but starting from a PNG so you can keep transparency.
- WebP → JPG — when you've been handed a WebP and need to send it somewhere that doesn't speak the format.
- WebP → PNG — when you need lossless and your destination doesn't take WebP.
The conversion-loss caveat
Two things worth knowing before you convert.
JPG → WebP doesn't recover quality. JPG already threw away detail when the file was saved. Converting to WebP packages the remaining pixels more efficiently, but the smearing and compression artifacts in the JPG are now permanent. The WebP isn't better than the JPG — it's smaller. Start from the highest-quality source you have.
WebP → JPG drops alpha. If the WebP has transparency, the JPG won't. You'll get a default-background-color fill (usually white) wherever the transparent pixels were. If transparency mattered, go to PNG instead.
And in general: every lossy round-trip costs a little quality. JPG → WebP → JPG ends up worse than the original JPG. Convert once from the best source, don't loop.
What about JPG XL, AVIF, all the new ones?
The image-format landscape keeps moving. AVIF (newer than WebP, even smaller files) has solid browser support now and is a credible WebP successor for the same web-only use case. JPG XL exists but doesn't have universal browser support yet. The picture-element <picture> with multiple <source> formats is the right way to serve all three with a JPG fallback for anything missing support.
For most jobs, today, the WebP-vs-JPG choice is the one that matters. Pick by destination, not by format newness.