Most guides on this question describe the formats and leave you to guess. We did the opposite: we took three real images, a photograph, a screenshot and a logo with a transparent background, and saved each one to JPG, PNG, WEBP and AVIF at a matched quality. The file sizes below are the actual bytes those encoders produced. They settle the argument faster than any description can.
The same three images, saved to every format
Each image was encoded once per format. The lossy formats (JPG, WEBP, AVIF) were set to quality 80; PNG is lossless, which is exactly why it behaves so differently depending on the picture.
| Image | JPG | PNG | WEBP | AVIF |
|---|---|---|---|---|
| Photograph 1280 × 863 | 180.5 KB | 1591.9 KB | 139.4 KB | 118.7 KB |
| Screenshot / UI 1400 × 1400 | 123.1 KB | 308.6 KB | 59.6 KB | 48.8 KB |
| Logo, transparent 512 × 512 | 8.9 KB* | 37.1 KB | 6.2 KB | 4.2 KB |
*JPG has no transparency, so the logo's background was filled with white. The transparent version simply cannot be saved as a JPG.
Three things jump out. WEBP was the smallest of the widely-supported formats in every single case. AVIF was smaller still. And PNG was either fine or a disaster depending entirely on the image, which is the part most people get wrong.
Look at the photograph on its own. As a lossless PNG it is a 1.59 MB monster; the very same picture is 139 KB as WEBP. That is not a rounding difference, it is more than ten times larger for no visible benefit.
Now the logo. Here PNG is reasonable and JPG is useless, because a logo needs its transparent background and JPG cannot keep one. WEBP and AVIF do both jobs, transparency and a tiny file, at once.
Try it on your own image
Numbers from our test images are useful, but your images are what matter. The tool below encodes whatever you give it to JPG, PNG and WEBP right here in your browser and shows the real sizes. Nothing is uploaded anywhere; pick a sample or drop in your own file.
What the numbers mean for each format
JPG is the safe photographic default. It is small, every device on earth opens it, and at quality 80 the loss is invisible for most photos. Its two hard limits are the ones the table shows: it cannot store transparency, and it is not the smallest option any more.
PNG is lossless, which is a strength and a trap. For flat graphics, logos, screenshots and anything with sharp text or transparency, lossless is exactly right and PNG stays crisp. Point it at a photograph, though, and it has to record every subtle pixel, which is how you get a 1.59 MB file. Use PNG for graphics, never for photos.
WEBP was the quiet winner of our test. It was the smallest widely-supported format for the photo, the screenshot and the logo, it does both lossy and lossless, and it keeps transparency. Every current browser reads it. For images going on a web page, it is the right default in 2026.
AVIF beat everything on size, sometimes by a wide margin. The catch is not viewing it, since modern browsers read AVIF fine, but creating it: support for writing AVIF is narrower and encoding is slower. It is an excellent choice when you control the pipeline, with WEBP as the safe fallback. We compared the two in depth in AVIF vs WEBP in 2026.
Lossy and lossless, and why it decides everything
Every choice above comes down to one distinction, and it is worth being precise about it because the words get used loosely.
Lossless means the file can be decoded back into exactly the pixels that went in, byte for byte. PNG works this way, and so does WEBP in its lossless mode. Compression comes from finding patterns and describing them more compactly, which is why a logo with three flat colours compresses enormously and a photograph, where almost every pixel differs slightly from its neighbour, barely compresses at all. That is the entire explanation for the 1.59 MB PNG in our table.
Lossy means the encoder is allowed to discard information the eye is unlikely to miss, mostly fine gradations of colour and subtle detail in busy areas. JPG, and WEBP and AVIF in their usual modes, work this way. Discarding data is what makes them small, and on photographs the discarded part is genuinely invisible at sensible quality settings.
Two practical consequences follow. First, lossy re-saves compound: each one throws away a little more, so editing a JPG repeatedly degrades it in a way that editing a PNG never does. Keep a lossless master and export lossy copies from it. Second, lossy compression fails hardest on exactly the content lossless handles best, which is sharp edges. That is why text in a screenshot saved as JPG picks up faint halos, and why the same screenshot as PNG stays clean.
So which format should you use?
| What you have | First choice | Fallback | Avoid |
|---|---|---|---|
| Photograph for a web page | WEBP | JPG | PNG, which can be ten times larger |
| Logo or line art | WEBP lossless, or PNG | PNG | JPG, which blurs hard edges and drops transparency |
| Screenshot or text-heavy graphic | WEBP | PNG | JPG, which halos the text |
| Anything needing transparency | WEBP | PNG | JPG, which cannot store it at all |
| Animation | A real video file, MP4 or WEBM | Animated WEBP | GIF, which is far larger for worse quality |
| Print, or handing a file to someone | JPG at high quality | PNG or the original master | WEBP and AVIF, which many print workflows reject |
| Smallest possible file, modern browsers only | AVIF | WEBP | Nothing, but keep a fallback ready |
The short version: default to WEBP for the web, keep JPG for sharing photos and PNG for graphics you need lossless, and reach for AVIF when you can. Google’s own performance guidance recommends modern formats like WEBP for exactly this reason. You can move any image between these with the image converter, and shrink it further with the image compressor.
Why JPG still matters
Given the numbers, it is fair to ask why anyone would still reach for the format that lost every round. The answer is that browser support and universal support are different things.
Every current browser reads WEBP, and that argument is settled. But images do not only live in browsers. They get attached to emails, opened in decade-old desktop software, imported into point-of-sale systems, printed by shops running fixed workflows, and passed to clients whose tooling you will never see. In that world JPG is the only format that is genuinely never a problem, and the cost of being wrong is a file someone cannot open rather than a page that loads slightly slower.
The rule that follows is simple. Use the modern format where you control the environment, which is your own website, and hand over JPG whenever the file leaves your control.
On the web you do not have to choose. The picture element lets the browser take the best format it understands and fall back on its own:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Description" width="1200" height="800">
</picture>Browsers read the sources in order and take the first they support, so anything older still gets the plain img tag at the end. That is why AVIF is safe to adopt today: the cost of a browser not supporting it is one extra file, not a broken page.
How we tested this
So you can judge the numbers rather than trust them: the three source images were a photograph (1280 × 863), a UI screenshot (1400 × 1400) and a transparent app icon (512 × 512). Each was encoded to JPG, WEBP and AVIF at quality 80, and to lossless PNG, using standard command-line encoders. The figures are the resulting file sizes in kilobytes, unretouched. Your own results will vary a little with the image and the quality setting, which is exactly why the tool above lets you measure yours.
