JPG vs PNG vs WebP: Which Image Format Should You Use?

A FiloTool benchmark encoded four source images to JPG, PNG, WebP and AVIF with sharp 0.34.5 on 2026-08-02, holding the lossy formats at quality 80. Two of those rows disagree with each other completely.

Start with a photorealistic landscape, 3,353,119 bytes as a source PNG. WebP produced the smallest file at 342,480 bytes, JPG came close at 391,819, and AVIF—the format usually described as the most efficient—produced 537,438 bytes, roughly 57% larger than the WebP. Now take a transparent graphic, 54,439 bytes. AVIF produced 18,644 bytes, comfortably the smallest, while re-encoding the PNG as PNG produced 61,830 bytes, which is 13.6% larger than the file it started from.

So AVIF was the worst choice on one image and the best on the other, and PNG managed to grow a file by saving it in its own format. The lesson is not that any of these encoders is bad. It is that a format recommendation which ignores image content is worthless.

With that caveat in place, defaults are still useful as a starting point—they are just a first guess to be tested, not a conclusion. Use JPG for a camera photo going into a broadly compatible upload form. Use PNG for a logo, diagram, screenshot, or graphic whose transparent or sharp edges matter. Use WebP for modern web delivery when the receiving browsers and publishing system support it.

JPG and the current WebP browser encoder discard some visual information as quality is lowered. This can soften texture, band gradients, or create ringing near text. PNG re-encoding is lossless; its quality buttons cannot force a smaller lossy PNG because browser Canvas exposes no PNG quality control.

JPG cannot store transparent pixels, so conversion must flatten them onto a background. PNG and WebP can store alpha. The FiloTool still-image conversion and compression paths do not promise to preserve animation; animated GIF or WebP inputs may become a first-frame or still result.

This is where a size comparison can quietly mislead you. On that transparent graphic, JPG produced 27,680 bytes against WebP's 29,038—so on a spreadsheet JPG looks like the winner by a small margin. It is not a comparison at all: the JPG achieved its size partly by discarding the alpha channel and flattening the image onto white. If transparency is part of the requirement, formats that cannot store it are disqualified before you compare bytes, not ranked alongside those that can.

For most real tasks the deciding factor is not compression at all—it is what the receiving system accepts. An upload form that rejects WebP, a print workflow that wants a specific container, a colleague opening the file in older software, or a platform that re-encodes whatever you send are all constraints that override any efficiency argument.

Work backwards from that. Establish what the destination will accept and what it does to your file after upload, and only then optimise within the formats that remain. A 40% saving in a format the destination rejects is not a saving. If the destination re-encodes everything anyway, sending a high-quality file and letting it do the work usually beats compressing twice—see how JPEG compression works for why repeated encoding compounds.

A format that measures well is only useful if your tools can create it and your readers can decode it, and that is a real constraint rather than a theoretical one. FiloTool's AVIF conversions rely on the browser's own native AVIF decoder, and its availability varies by browser version—so the format that produced the smallest transparent graphic in the benchmark is also the one most likely to be unavailable in whatever is opening the file.

Animation is a harder boundary. The still-image conversion paths take the first frame and nothing else; an animated WebP going through them arrives as a single frame, with a notice when animation is detected. If motion is part of the asset, none of the still formats on this page is the answer and no compression setting will change that.

Open the Image Converter when changing formats, or use the format-specific JPG Compressor, PNG Compressor, and WebP Compressor when the container should stay the same. Compare the result at its final display dimensions.

The FiloTool image format comparison publishes the full sixteen-row result set behind the two examples quoted above, along with the encoder versions, quality settings, PSNR and RMSE figures, and notes on what the artifacts actually looked like at 100% zoom. Read it when you want the evidence rather than the summary.

Then treat it as an illustration rather than a lookup table. Those measurements describe four specific images at one quality setting, and this page exists precisely because a different photograph, logo, or screenshot can rank the formats differently. The reliable answer comes from testing your own file, not from memorising someone else's benchmark—including ours.