Image Compressor - What Each Format Actually Costs in Bytes
Measures compression instead of promising it: real bytes out for every format your browser encodes, a quality search when you must fit a target size, and what the metadata and transparency lose.
Measured, not estimated
| What | Setting | Pixels | Bytes | Against your file |
|---|
What this path does on the way
| Change | What happens to it | This run |
|---|
What your browser answers when asked for a format
| Asked for | Came back as | Verdict |
|---|
What lossy compression throws away
The path: decode to pixels, re-encode in your browser
There is no second hand here: the picture is decoded into a rectangle of pixels and then asked back out through your browser’s own encoder. Everything the tables measure follows from that. The bytes coming out are written by the encoder shipped inside your browser, and what gets reported is the file that comes back, not an estimate of what it should be.
That is also why a result can come back larger than the source. A re-encode starts from raw pixels, so a file that was already squeezed carefully has nowhere to go but sideways or up. Most pages of this kind show a slider and a percentage nobody measured; the number shown here is the one your browser actually wrote, including on the runs where it went the wrong way.
Why the quality number is not a size
Quality is a dial into an encoder’s internals, not a target. JPEG at 80 on a detailed photo and JPEG at 80 on a flat logo are wildly different files, because the number trades the same way in both and there is far less to throw away in the second one. So two things happen: the bytes get printed, and if a size in kilobytes is given, the ladder gets searched for the highest rung that still fits under your figure - your ceiling first, then quality 1, then halving the gap between them, six encodes at most.
When six encodes are not enough to close the gap, that gets said, and the rungs that were never measured get named. It will not quietly drop pixels to make your number: fewer pixels is a different decision, it belongs in the longest edge box, and the file you get should be the one you chose.
What the canvas throws away
A canvas holds pixels. Everything else a picture file can carry - the camera and lens, the date taken, the GPS block, the rotation flag, the colour profile, an embedded thumbnail, comments - lives outside the pixel rectangle, so nothing is being stripped deliberately: a canvas never sees it. That is worth pausing on before you send a compressed photo somewhere as proof of where you were standing when you took the original.
The file that comes back is not bare pixels either. An encoder writes a header of its own around whatever it is handed - a format marker, sometimes a colour tag - and those bytes are counted in every table, because the tables measure what your browser actually produced rather than what an encoder was hoped to produce.
Transparency is the other one, and it is format-dependent: PNG, WebP and AVIF carry an alpha channel and JPEG does not, so a transparent source going out through the JPEG path becomes one flat colour. Which colour is your browser’s decision, and the only thing reported about it is that the question was asked.
Why the format list is a question, not a statement
Nothing is shipped as a list of formats your browser can encode. As soon as the script starts it asks for four of them, one at a time, and looks at what comes back. An encoder that does not know a requested type answers with a PNG instead, which is precisely how you would otherwise end up with a file named .avif holding PNG bytes - so the table prints what was asked for, what arrived, and only offers the ones that matched.
That is why the refusal is worth trusting: it is your browser’s behaviour, measured on your machine a second before you asked for anything.
Questions
Q: Does my picture get uploaded? No. The file is read by your browser’s own image decoder, the pixels are handled on a canvas, and the output is a blob in this tab’s memory that a save link points at. Nothing is sent anywhere, and the byte counts in the tables are the sizes of that blob.
Q: Why is my PNG bigger after this than before? Because PNG is lossless, so there is no quality setting to turn, and the re-encode has to write every pixel your browser’s resampler produced. If a PNG must get smaller through here the lever is fewer pixels - and then read its row against the WebP at the same pixels, which is usually the smaller file.
Q: Can I get the date taken back? No, and nothing else here can either. Keep the original file, or read the metadata before compressing and write it back afterwards with a tool that carries a real EXIF writer.
Q: What is the largest picture that can be taken in? It takes 20 MB in, which is a rule about memory rather than about files: a decoded rectangle costs about four bytes per pixel, so a 6000 x 4000 photo is roughly 96 MB before any encoder starts, and it is your tab that has to hold it. Big scans belong in a program that can stream them.