PNG vs JPG vs WebP: which should you use?

The short answer

What I measured, and how

Four images, each 1280×960 pixels, each encoded to PNG, to JPEG at four quality settings, and to WebP at two. The encoders are Chromium’s, reached through canvas.toBlob(type, quality) — the same call every image tool on this site makes, so these are the sizes this site’s converter would actually produce.

The test images are drawn by a seeded generator rather than being photographs I own. That is a deliberate choice and the main thing that makes this repeatable: you can regenerate byte-identical inputs on your own machine and check every number below, which you could not do if I had used a picture from my phone. What each one stands for:

• Photograph. A camera photo: a landscape, a portrait, anything with continuous tone. What decides the result: Smooth tonal variation with detail at several scales and almost no exactly repeating pixels.
• Flat graphic. A logo, a chart, an icon, a diagram exported from design software. What decides the result: Large areas of a single color meeting at hard edges, and only a handful of colors in total.
• Screenshot. A screenshot of an app, a settings panel, a table, a page of documentation. What decides the result: Small high-contrast text on flat panels — the case JPEG handles worst.
• Logo with transparency. A logo saved with a transparent background, to be placed over something else. What decides the result: An alpha channel, which JPEG cannot store at all.

The measurements

Why your PNG is so big

This is the most common version of the question, and the answer is that PNG is doing exactly what it was designed to do. It is lossless: it stores the precise value of every pixel and throws nothing away. That is excellent for a logo with twelve colors and terrible for a photograph with hundreds of thousands, because a photograph has almost no exactly repeating pixels for a lossless compressor to collapse.

The photograph here was 2.07 MB as a PNG and 104 KB as a JPEG at quality 85 — 20.0x larger. The flat graphic went the other way: 50 KB as a PNG, which is a perfectly reasonable size, and JPEG saved only -45% while adding artifacts around every edge.

So a large PNG is not a fault to be fixed with a compressor. It is a sign the format does not match the content. If the picture is photographic, the fix isconverting it to JPG or WebP — and if it also has far more pixels than it will ever be displayed at, resizing it will save more than either.

WebP was smaller every time — with one condition

WebP at quality 85 beat JPEG at quality 85 on all four images, by 2.3x smaller on the photograph and 2.7x smaller on the flat graphic. Against PNG on the graphics, where you might not expect a lossy format to be usable at all, it was 4.9x smaller on the flat graphic and 3.0x smaller on the screenshot. WebP also carries an alpha channel, so on graphics it is competing with PNG on both counts rather than only on size.

The condition is support, not size. WebP is fine in every current browser and still rejected by plenty of desktop and business software that predates it. That is the entire reasonWebP to JPG exists as a tool: not because JPEG is better, but because something at the other end will not open the file. If you control the destination — your own website, for instance — WebP is close to a free win. If you are sending the file to someone else, send a JPEG.

The round trip that costs you twice

The single most expensive mistake in this whole area is converting a JPEG to PNG in the hope of improving it. It cannot work, and it is worth seeing what it actually costs. I took each test image, encoded it to JPEG at quality 85, and then converted that JPEG to PNG — exactly what happens when someone runs a photo through JPG to PNG expecting a better file.

For the graphics the result is the worst of both formats at once. The screenshot came back 2.7x larger than the PNG you would have had if you had never touched JPEG, and it now contains JPEG’s artifacts permanently. The reason is worth understanding: JPEG replaces the flat blocks of color that PNG compresses brilliantly with thousands of slightly different values. PNG then faithfully, losslessly stores all that new noise.

The photograph is the apparent exception — its round-trip PNG was 1.6x smaller than the original. That is not a saving. The file is smaller because JPEG smoothed real detail out of the image, leaving less for PNG to store. You paid 1.26 MB for a file that holds strictly less than the 104 KB JPEG it came from.

There is exactly one good reason to do this conversion: you need a PNG because the next step in your workflow demands one, and you accept the size. Converting to PNG will never undo JPEG.

Transparency is discarded, not compressed

The logo with a transparent background was 52 KB as a PNG and 22 KB as a JPEG — smaller, and useless for the purpose, because JPEG has no alpha channel. The transparent area does not survive in reduced form; it is composited onto a flat background, and this site’s PNG to JPG tool fills it with white and says so. Once that is done, the transparency cannot be recovered from the JPEG. If you need the subject on its own, keep a PNG or a WebP, or use the background remover to produce one.

The result I nearly published, and why I did not

The first version of the photograph generator built its detail from per-pixel random noise. On that image, WebP came out 4.7% larger than JPEG at quality 85, and I had most of a paragraph written about how WebP’s advantage is overstated on photographs.

It was an artifact of my own test image. Random noise is incompressible by construction, and a photograph is not — real photographic detail is spatially correlated, which is precisely what modern codecs exploit. I was measuring a defect in the generator and preparing to report it as a fact about WebP. Rewriting the generator to build detail from several octaves of correlated noise, which is a far better model of a photograph, reversed the result completely.

Rather than quietly delete that, here is the sweep across grain amplitudes. The published photograph row uses a grain of 6.

There is a real finding in here, which is more useful than the one I almost got wrong: WebP’s advantage over JPEG is large on clean detail and disappears entirely once heavy grain or sensor noise dominates the image. If you are compressing a high-ISO night photo or something with film grain, do not assume WebP will win — measure both. On an ordinary daylight photograph it wins comfortably.

Limits of this test

• Generated images, not photographs. The four inputs are models of three content classes, chosen so anyone can regenerate them exactly. They capture the property that drives each result — continuous tone, hard edges, small text, an alpha channel — but a real photograph of a particular scene will not land on precisely these numbers.
• One encoder. These are Chromium’s encoders. libjpeg-turbo, MozJPEG, Squoosh and Safari all produce different sizes at the same nominal quality, and JPEG quality numbers are not standardized between implementations anyway.
• Size only, not perceived quality. I measured bytes. I did not run a perceptual metric or a blind comparison, so nothing here says WebP at 85 and JPEG at 85 look equally good — only what each one weighs.
• One size. Everything is 1280×960. Ratios shift with resolution, and PNG’s disadvantage on photographs grows as images get larger.
• Default encoder settings. No chroma subsampling changes, no progressive JPEG, no PNG post-processing with a tool like oxipng, which would have narrowed PNG’s gap somewhat on the graphics.

Repeat it yourself

The script that produced every number on this page is scripts/measure-image-formats.mjs in this site’s repository. It needs Node and Playwright, takes about ten seconds, and prints the table as JSON:

node scripts/measure-image-formats.mjs
node scripts/measure-image-formats.mjs --grain-sweep

If your numbers differ from mine by more than a rounding, I would like to know — a different Chromium version is the likeliest cause, and it would be worth saying so on this page. Send it through the contact page.

And if you just want the conversion rather than the argument: the batch converter moves between JPEG, PNG and WebP, the compressor keeps the format and trades quality for size, and the resizer is the one that usually saves the most.