The Best Image Formats for the Web: JPG vs PNG vs WebP

The format question is usually asked backwards. People want to know which format is best before they have decided what the image is for — and the answer changes completely between a photograph, a screenshot and a logo. Decide the job first, and the format picks itself.

The short answer

If you remember one line: photographs want a photographic codec, graphics want an exact one, and everything you can convert to WebP should probably be WebP.

JPEG: still the safe photograph format

JPEG compresses by throwing away detail your eye is unlikely to miss — fine gradients and high-frequency noise are simplified, which is why a photograph survives the treatment and a screenshot does not. Text, thin lines and hard edges pick up visible ringing and blur, which is why a JPEG of a screenshot always looks slightly wrong.

JPEG is lossy and generational: every time you open a JPEG, edit it and save it again, you compress an already-compressed image. Keep one untouched master and export from that, never from the last export.

JPEG also has no alpha channel. If you need a transparent background, it is the wrong format before you start.

PNG: exact pixels, and the price that comes with them

PNG is lossless. Every pixel you save comes back identical, transparency is fully supported, and hard edges stay hard. That makes it the right choice for screenshots, UI captures, diagrams and logos with transparency.

The cost is size: PNG was built for exactness, not for photographs. A PNG of a hero photo is often several times heavier than the same picture as a JPEG or WebP, and no amount of optimization settings will close that gap, because the format is doing exactly what you asked of it.

WebP: the format the web actually settled on

WebP does both jobs. It has a lossy mode for photographs and a lossless mode for graphics, it supports transparency and animation, and every current browser can render it. Google’s own documentation for the format puts lossless WebP around a quarter smaller than the equivalent PNG, with lossy mode going considerably further on photographic content.

For most sites the practical rule is simple: if it is an image that renders in a browser, try WebP first. Keep the PNG or JPEG as the master you edit, and treat the WebP as the build output.

AVIF, GIF and SVG in one paragraph each

AVIF is the newest of the three general-purpose formats and it can beat WebP on file size at equal quality, particularly on large photographic images. The trade is tooling: encoding takes longer, some editors still cannot open it, and very old browsers cannot display it. Serving it alongside WebP in a <picture> element is the usual compromise.

GIF survives for one reason: it animates everywhere. It is also limited to 256 colours per frame and produces surprisingly large files for anything with gradients. A short video file, or an animated WebP, is almost always smaller and better looking.

SVG is not an image format in the same sense at all — it is markup that describes shapes. For logos, icons and diagrams it is unbeatable: it scales to any size, stays sharp on every display, and is usually a fraction of the weight of a bitmap. It is the wrong tool for photographs, and it needs care with accessibility and with optimization, but for interface graphics there is nothing close.

How to choose without overthinking it

1. Is it a logo, icon or diagram? Use SVG. Stop here.
2. Is it a screenshot, interface capture or a graphic that needs transparency? Start from PNG for the master, publish WebP.
3. Is it a photograph or a rendered illustration? Publish WebP, or AVIF with a WebP fallback if you are chasing the last few kilobytes.
4. Is it animated? Prefer a video format; if it must be an image, animated WebP beats GIF.
5. Is a platform refusing anything but JPEG or PNG? Send the required format, as small as you can make it, and know you have left something on the table.

Two formats of the same picture are cheap to keep and easy to serve — a <picture> element with a WebP source and a JPEG fallback costs a few lines and covers the whole audience:

<picture>
  <source srcSet="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Describe the image" width="1200" height="675" />
</picture>

Note the width and height attributes. They let the browser reserve the space before the image arrives, which is how you avoid the layout shift that makes a fast page feel unstable.

Dimensions before compression

This is the part that gets skipped. Compression reduces the cost of each pixel; resizing removes pixels that were never going to be displayed. If a hero image renders at 720 CSS pixels on a 2× display, it needs about 1440 real pixels across. Serving 2400 costs you roughly two and a half times the bytes before the encoder has done anything.

So the order is: decide the largest size it renders at, resize to that, then compress, then convert. Doing it the other way round means optimizing bytes you should not be sending at all.

Convert and compare on your own file

Every figure above is a generalisation. Your image is the only benchmark that matters, and the honest way to settle the question is to convert it and look at both versions.

• Image Converter moves a file between PNG, JPG, WebP, AVIF and GIF — 24 MB per file, up to 10 files at a time.
• Image Optimizer shows the result next to the original with the before and after sizes, so you can judge the trade at a glance.
• Image Resizer fixes the dimensions, which is the change worth making first.
• PNG to WebP: how much smaller are the files, really? walks through one conversion in detail, numbers included.