Three formats, one recurring argument
Every image on the web is a compromise between quality and weight, and the format you pick decides the terms. JPG, PNG, and WebP are not three flavors of the same thing. They make different bets. JPG bets that photos can lose detail nobody notices. PNG bets that some images must survive perfectly. WebP bets it can do both jobs with newer math.
My qualifying mistake for writing this: I once shipped a photographer's portfolio homepage with every image exported as PNG, because PNG sounded like the professional choice. The page weighed over 40 MB. On a hotel wifi connection it took the better part of a minute to load. Converting those photos to a lossy format cut the page to a small fraction of that weight with no visible difference on screen. Professional is what loads.
How each format thinks
JPG is lossy compression built for photographs. It divides the image into small blocks and discards fine detail the eye tends to miss, which works beautifully on smooth, continuous tones like skin, sky, and foliage. Push the quality slider down and the discarding becomes visible as blocky smudges, worst around sharp edges and text.
PNG is lossless. Every pixel comes back exactly as saved, which makes it perfect for screenshots, diagrams, logos with flat color, and anything containing crisp text. It also supports full alpha transparency. The price is size: on photographs, where almost no two adjacent pixels match, lossless compression has little to squeeze, and files balloon.
WebP is the newer generalist. It has a lossy mode that outperforms JPG at matched quality and a lossless mode that beats PNG, and both modes support transparency. Google's own study, linked below, puts WebP lossy files at roughly 25 to 34 percent smaller than comparable JPGs, and WebP lossless around 26 percent smaller than PNG. Browser support has been effectively universal for years.
The size math, done honestly
Real numbers beat adjectives, so here is transparent arithmetic rather than benchmark theater. A 12 megapixel photo, 4000 by 3000 pixels, holds 12,000,000 pixels at 3 bytes each uncompressed: 36 MB of raw data. A typical high quality JPG compresses photographs at roughly 10 to 1, a widely used rule of thumb, landing near 3.6 MB. Apply Google's measured 25 to 34 percent saving and the WebP version of that same photo lands around 2.4 to 2.7 MB.
Now flip the content type. A 1920 by 1080 screenshot of a flat interface compresses brilliantly as PNG because thousands of adjacent pixels are identical; runs of same-colored pixels are cheap to encode. Save that screenshot as JPG and you get a larger file with fuzzy halos around every letter, the worst of both worlds. The content decides the winner, not the format's reputation.
One caveat the marketing never mentions: those percentage savings are averages at matched perceptual quality. On an individual image, a well tuned JPG can occasionally tie or beat a lazily encoded WebP. Convert with an image to WebP tool, then compare the before and after sizes yourself instead of trusting the average.
Transparency changes everything
JPG has no transparency at all. Export a logo on a transparent background as JPG and the transparency becomes a solid white or black rectangle. This single limitation explains most of PNG's survival: for years, any image that had to float over a varied background had exactly one realistic choice.
WebP removed that excuse. Its lossy mode supports a full alpha channel, meaning a photographic image with soft transparent edges, previously a guaranteed multi-megabyte PNG, can ship at a fraction of the weight. If you maintain a site full of transparent PNGs, product cutouts especially, converting them is one of the cheapest performance wins available.
The place transparency questions really belong, though, is one level up: if the graphic is a logo or an icon, the right question is not which raster format but whether it should be raster at all. I wrote about that decision in SVG vs PNG: when to use each, and when a vector does need rasterizing, an SVG to PNG conversion at the exact target size beats scaling ever after.
When WebP does not win
WebP is the right default for the web, but default is not law. Email clients are the big exception: support in email rendering remains inconsistent enough that JPG and PNG are still the safe attachments and newsletter formats. Print workflows and older design tools can also reject WebP, and some stock and marketplace upload forms still whitelist only JPG and PNG.
There is also the recompression trap. Converting an already compressed JPG to WebP re-encodes lossy data with lossy math. The file usually shrinks, but you are stacking two generations of quality loss. When you can, convert from the original export, not from the compressed survivor. And if a platform demands JPG anyway, running it through an image compressor at a sane quality setting recovers most of the win without changing format.
Dimensions before formats, always
The most common image weight problem on real sites is not format choice. It is a 4000 pixel photo displayed in a 400 pixel slot. No encoder rescues that. Scaling the file to roughly its display size cuts the pixel count enormously before compression even starts; our 12 megapixel example shrunk to 800 by 600 is 480,000 pixels, a 96 percent reduction in raw data, because 480,000 divided by 12,000,000 is 0.04.
So the order of operations is: size the image with an image resizer to what the layout actually displays, then pick the format by content type, then compress. Format is the second decision, and it only looks like the first because it is the one people argue about.
The decision in four lines
After all the nuance, the working rules fit on an index card.
- Photograph for the web: WebP lossy. Fall back to JPG only where WebP is refused.
- Screenshot, diagram, or flat graphic that must stay pixel perfect: PNG, or WebP lossless where accepted.
- Anything needing transparency: WebP with alpha for the web, PNG for email and picky platforms.
- Logos and icons: pause and consider SVG first; rasterize only at the sizes you actually need.
Questions people ask
On average yes, by roughly 25 to 34 percent at matched quality per Google's published study, but averages hide exceptions. An individual well-optimized JPG can tie or occasionally beat a poorly encoded WebP. Compare actual file sizes after converting rather than assuming.
Slightly, yes. Both are lossy, so you stack a second generation of loss on the first. The visible effect is usually negligible at reasonable quality settings, but convert from the original uncompressed export whenever you still have it.
Screenshots and UI images with crisp text, graphics that must be pixel perfect, transparency for email and platforms that reject WebP, and any upload form that only accepts JPG or PNG. PNG is not obsolete; it is specialized.
AVIF often compresses even smaller than WebP and browser support is now broad, but encoding is slower and tool support is patchier. WebP remains the safe modern default; AVIF is worth testing if you control your whole pipeline and chase every kilobyte.
