The Conversion Lab

Almost every guide to image formats will tell you that WebP is smaller than PNG, or that JPG is smaller than everything. Pages on this site used to say things like that too. The problem is that such claims are only true for some pictures, and the exceptions are not small: on our own PNG → JPG page a photograph shrinks by 85%, while a screenshot of an application grows by 142%. Same page, same settings, opposite advice.

So we stopped asserting and started measuring. Every converter listed below now runs against the same small set of test images, and the file sizes printed on those pages are the bytes that actually came out of the tool in a real browser. This page documents how that is done, what we chose not to measure, and where to get the test files if you want to check our numbers.

The test files

A benchmark is only as honest as its inputs. We deliberately did not use stock photographs: they come with licences, they cannot be republished, and a number nobody can reproduce is not evidence. Instead all four images are drawn from scratch by a script with a fixed random seed, so the exact same bytes come out every time — and every source file is published below for download. Each one is picked to break a different compression assumption.

Photo-like

Soft gradients plus fine strands and film grain — the high-frequency detail a real photo has.

Download: PNG 1.88 MB JPG 330.2 KB JFIF 330.2 KB WEBP 351.5 KB BMP 2.75 MB TIFF 2.75 MB AVIF 122.3 KB HEIC 886.6 KB

UI screenshot

Large flat areas and hard 1-pixel borders, like a screenshot of an app.

Download: PNG 18.0 KB JPG 45.3 KB JFIF 45.3 KB WEBP 7.3 KB BMP 2.75 MB TIFF 2.75 MB GIF 10.2 KB AVIF 1.4 KB HEIC 21.9 KB

Flat illustration

Six solid colours in big shapes, no gradients at all.

Download: PNG 34.7 KB JPG 25.6 KB JFIF 25.6 KB WEBP 10.8 KB BMP 2.75 MB TIFF 2.75 MB AVIF 3.2 KB HEIC 26.0 KB

Logo with transparency

Hard edges, few colours, and a transparent background.

Download: PNG 28.8 KB WEBP 7.6 KB GIF 4.3 KB HEIC 25.1 KB

Vector diagram

A hand-written SVG: solid shapes and one curved stroke, 574 bytes of text.

Download: SVG 574 B

5-page mixed PDF

Four text pages plus one full-page photograph, so the pages differ enormously in weight.

Download: PDF 334.1 KB

3-page text PDF

Nothing but text — the second file for the merge test.

Download: PDF 2.8 KB

How the numbers are produced

There is no estimation step anywhere in this. For every row in every table, a script:

1. draws the test images on a browser canvas and writes them to disk;
2. opens the real /convert/… page from the deployed build;
3. puts the file into that page's own file input — the same code path you use;
4. waits for the download link to appear, fetches the resulting blob and reads its exact byte length.

Every figure on this site was produced that way on 2026-07-28 with Chromium 151.0.7922.34, using each page's default settings unless the table says otherwise.

Two caveats we would rather state than bury. First, image encoders live in the browser, not on our server, so a different browser or a newer Chromium can return slightly different sizes — these numbers are reproducible, not universal. Second, file size is not image quality: a smaller file can easily look worse, and none of these tables measure how the result looks.

What we did not measure, and why

A browser canvas can only encode three formats — ask Chromium 151 for image/avif, image/gif, image/bmp or image/tiff and you get a PNG back. So for anything outside PNG, JPEG and WebP we had to write the encoder ourselves. We have now done that for three: an uncompressed 24-bit BMP, an uncompressed baseline TIFF (which is what scanners often produce), and a GIF89a with LZW compression.

GIF is only partly covered, and the reason is GIF itself: it holds at most 256 colours. We counted the colours in our own test images — the UI capture has 13 and the transparent logo 12, so both encode exactly. But the flat illustration has 490 and the photograph 200,374, because the anti-aliased edges of the circles and the film grain produce hundreds of intermediate shades. Quantising those down would make a different image, and comparing its size against the original PNG would be meaningless. So the GIF rows use the two images that genuinely fit — which happen to be exactly what GIFs are used for in practice: flat interface captures and transparent stickers.

AVIF took a different route. An AVIF payload is an AV1 video frame, and an AV1 encoder is not something anyone writes by hand in a few hundred lines. So we generated those test files with ffmpeg and libaom-av1: -crf 23 -cpu-used 4 -still-picture 1 -pix_fmt yuv420p. The crf was chosen to sit near the quality 92 used for the JPEG and WebP sources — pitting a low-quality AVIF against a high-quality JPG would not be a fair fight. Reaching for an outside tool does not weaken the claim, because the rule here was never “the file must be born in a browser”; it is “the file must be published so anyone can reproduce the number”. The three AVIF files and the exact command are both published, so both halves can be checked.

HEIC: we said this was impossible, and we were wrong. This page used to state that HEIC could not be measured — that the ffmpeg build here has libx265 but no HEIF muxer, and that no browser or npm encoder could write a .heic either. The first half was true. The second half was us turning one tool’s limit into a general one. libheif ships its own x265 encoder, and reaching it through pillow-heif produced the four test files on the first attempt, at quality 92 to match the JPEG and WebP sources. All four are published with the rest. Worth stating precisely: these are libheif-encoded HEIC files, not photographs off an iPhone — Apple’s are often 10-bit 4:2:0 carrying their own orientation and EXIF, so your numbers will not match ours exactly. One limit does remain: there is no transparent AVIF in the corpus, because the ffmpeg AVIF muxer does not write the alpha auxiliary item and the file it produces is opaque. Checking whether transparency survives, with a file that is not transparent, would be theatre. HEIC did keep its alpha — the corpus script decodes every file straight back to verify that, and drops anything that loses it rather than publishing it.

The PDF tools were absent at first for a different reason — we assumed merging or rotating a PDF was not a file-size question. That was wrong, and the numbers are the interesting part: extracting page 3 of our test document gives 331.2 KB while page 4 gives 1.4 KB, from the same file. So all nine PDF converters are now measured too, against a 5-page document whose pages differ enormously in weight.

That puts all 38 converters on measured numbers. It is 38 rather than 36 not because we lowered the bar, but because the paragraph above used to be wrong — and fixing a sentence like that means going and finding the encoder, not editing the number.

Every measurement in one place

The same data that appears on the individual converter pages, all together. Percentages are relative to the source file. If you would rather read the conclusions than the table, we wrote them up as a decision guide: which format should you convert to, organised by what is actually in your image.

Repeat it yourself

Nothing here depends on our cooperation. Download a test image above, open the matching converter page, drop the file in, and compare what the tool reports with the row in the table. The tools run entirely in your browser, and the source files are the same ones we used.

Six things the whole table taught us

1. There is no "smaller format", only a smaller format for a given picture. The single widest spread in the data is one converter with default settings: −85% for the photo, +142% for the screenshot.
2. WebP wins almost everywhere — but "almost" is the honest word. From PNG, JPG, BMP and TIFF sources every WebP output was smaller than its input. From AVIF it never was, and could not be. Then we added GIF and found the exception: our 4.3 KB transparent GIF came out at 5.4 KB, up 27%. A modern codec has little left to win against a 4 KB palette image.
3. Converting to a lossless format never recovers quality but always costs size. JPG → PNG grew the photo by 542%, and the image is still exactly as damaged as the JPG was.
4. BMP file size is completely independent of content. All three BMP sources are byte-for-byte 2.75 MB, whether they hold a noisy photo or six flat colours. That is what "no compression" means in practice.
5. Vector to raster is a one-way door. A 574-byte SVG becomes 6.6 to 17.9 KB once rasterised and stops being scalable, and going back the other way only works on flat art — tracing the photo produced a 7.74 MB pile of paths.
6. The most lopsided rows in the table are the AVIF ones, and they are a compliment to AVIF. Our 1200 × 800 UI capture fits into 1,472 bytes as AVIF; converting it costs +378% as WebP, +2442% as PNG and +2942% as JPG. There is no size argument for leaving AVIF, only a compatibility one — which is exactly what those three pages are for.