Hacks VitaeAll tools
freecompressconvert
measured, not averaged

JPG vs WebP vs PNG, on your files

Every guide quotes an average taken from somebody else's photographs. This measures yours: every format, every quality setting, the real byte count. It runs on your machine, so the files never leave.

Drop images to measure

· up to eight at a time

Seventeen encodes per image, so a large photo takes a moment.

Nothing measured yet.

Quick answer

Which format should you actually use?

// Answer

Photographs: WebP if the destination accepts it, JPG if it must be safe everywhere. Screenshots, logos, anything with sharp text or flat colour: PNG. Quality setting: start at 85 and look at the knee in your own table. Lower settings make flat areas like skies go blotchy sooner.

Method

How the numbers are produced

Each image is decoded to raw pixels once, then encoded seventeen times: JPG and WebP at eight quality settings each, plus one lossless PNG. Nothing is resized, so the only variable is the encoder and its quality setting. The byte counts are the actual encoded sizes, read from the resulting files.

The encoders are the ones built into your own browser. That is worth saying plainly, because it means two people can get slightly different numbers from the same photo on different browsers, and both are correct for their own machine. The exception is Safari, which cannot save WebP from a web page: there the WebP column reads “not supported”, so run the benchmark in Chrome, Edge or Firefox to compare WebP. A server-side benchmark would hide that behind one library's behaviour.

The knee is defined by a stated rule rather than by eye. Each step from one quality setting to the next costs a certain number of extra bytes per quality point. Take the median of those costs, then find the first step that costs more than twice it: that is where the curve turns, and the setting below it is the last cheap one. The whole curve is in the table, so you can apply a different rule if you prefer.

What the curve usually looks like

Three things worth knowing before you look

  • The top of the scale is nearly all waste. Going from 90 to 100 typically multiplies the file size while changing almost nothing you can see at normal viewing size. If a page feels slow, that setting is the first place to look.
  • Resizing beats quality, and it is not close. Halving the width quarters the pixel count. No quality setting can match that. Try the same image in the resizer and compare.
  • Content decides everything. A photo of a foggy beach compresses beautifully. A photo of gravel does not. Anyone quoting one percentage for "images" is averaging over pictures that are nothing like yours.
What to do with the answer

Once you know your number

If the goal is a size limit rather than a quality setting, the compressor will hunt for the highest quality that fits a byte budget you type in. If the goal is a page that loads faster, resize first with the resizer, then apply what you learned here. If you came from an iPhone, HEIC converts here too, and the same curve applies to the JPG that comes out.

One thing the table cannot tell you: whether the picture still looks right. Bytes are measurable and appearance is not, so check the result at the size people will actually see it, not zoomed in.

FAQ

Frequently asked questions

Because those numbers came from somebody else's pictures. Compression depends almost entirely on what is in the image. A flat graphic, a screenshot full of text, a noisy night photo and a studio portrait behave nothing alike. An average across a stock photo set tells you very little about the file on your desk.
The quality setting past which the file grows faster than the picture improves. The rule used here is stated rather than felt: measure how many extra bytes each quality point costs between steps, take the median of those, and find the first step costing more than twice it. The setting below that is the knee. The whole curve is in the table, so you can apply your own rule and disagree.
No, and the table will show you where it is not. WebP usually wins. The two quality scales do not mean the same thing, so at a given setting WebP can come out larger on some images. This is exactly the kind of claim worth checking on your own files rather than taking on trust.
Because PNG is lossless. Nothing can be thrown away, so a re-save only changes which encoder wrote the file. Depending on how the original was written, the result can come out larger.
No. Every encode happens in this tab, on your machine. That is what makes it safe to benchmark files you would never hand to a website, and it is also why the measurement is of your real files rather than a sample.

Ask an assistant about this page

Opens in a new tab with this page and the question already filled in.

ChatGPTClaudePerplexityGemini