Which format should this picture be in?

Most format advice is written about somebody else’s picture. An article that says WebP is twenty-five per cent smaller than JPEG is reporting an average over a corpus that does not contain your file, and averages are a poor guide to a decision about one photograph of one thing in one light.

So this runs the comparison on your file instead. It decodes it once, then writes it into each candidate format, searching that encoder’s own quality parameter until the result measures within the distance you asked for. What comes back is the size of the file that search produced, which is a fact rather than an estimate.

The download is the last and cheapest step. If the numbers say your original is already the best version of itself, the page says so and there is nothing to save — which is the one outcome a converter is least inclined to suggest and the most useful one it has.

Each card carries four figures. Size is the length of the file the encoder produced, in bytes, with the difference against your original beside it. Quality is the setting the search landed on, between 0 and 1 — a result, not a knob you set. Measured is how close the produced file is to your source on the structural-similarity scale, where 1.0000 is indistinguishable by that measure. Encode is how long the pass that produced that file took on this device, not a figure from a table.

The two panes are there because a number can only take you so far. Drag the divider, zoom to 800 per cent, and hold the space bar to put your own file in both panes for as long as you hold it. If something looks wrong at 800 per cent that measured fine, trust your eyes and use the next position up on the quality control.

JPEG, PNG, WebP, AVIF, GIF, BMP, TIFF and ICO are read directly; HEIC from an iPhone is read through a decoder that is fetched from this site only when a HEIC actually arrives. The format is worked out from the bytes at the start of the file, never from the name, because a file called photo.jpg is under no obligation to be one.

Some things it deliberately will not do. It does not edit: the pixels that come out are the pixels that went in, re-encoded. It does not chase a target in kilobytes — if the file size is the problem rather than the format, compresspicture.com is built for that question. And if what you actually need is a document rather than an image — several pages, in order, that someone can print — convertphotostopdf.com is the right tool and this one is not.

Very large pictures are offered on a lighter working copy rather than refused outright, and the page says when it is working from one. Anything above the hard ceiling is declined with the actual number in the message.

Why not just set every encoder to quality 80 and compare?

Because the number means something different in each one. It is an index into that encoder's own internal tables, not a measurement of anything, and equal values produce visibly unequal pictures. This bench searches each encoder's parameter until the file it produces measures within a set distance of your original, then reports the setting it landed on as a result rather than as an input.

What does the measured figure on each card mean?

It is multi-scale structural similarity between the produced file, decoded again, and your source — 1.0000 means the two are identical by that measure and anything lower is further away. It is computed on a 512-pixel reference so the cost does not grow with your file, and it is a statistic, not an eye.

Why is my picture sometimes larger in every format?

Because it was already encoded well. A JPEG that came out of a good encoder is close to what the format can do with those pixels, and putting it through a second encoder adds loss without buying space. When that happens the recommendation says to keep the file you already have, which is the only honest answer available.

Does anything leave this device?

No. The decode, every encode, the scoring and the download all happen in this tab. There is no server behind this site to send a picture to — it is a set of static files and a worker thread.

Why is AVIF missing from the bench?

Because the encoder measured too slow to present honestly. A single-threaded WebAssembly build took 3.3 seconds for one 12-megapixel pass on a fast laptop at its quickest useful setting, and the quality search needs up to seven passes. On a mid-range phone that is minutes. The reference page for the format is here, with the measurements written down, and the encoder arrives when it can run in a time worth waiting.

My file is a screenshot. Why is JPEG marked as the wrong tool?

Flat colour and hard edges are exactly what a lossy photographic encoder handles worst: it softens the edges and rings around them, and it spends bytes doing it. The bench detects few distinct colours and a high proportion of hard edges, marks JPEG accordingly, and judges the lossless candidates instead.

There is more on the measurement itself in what quality really means, and a reference page for each format with its support table and its failure modes.