image compression lab
what quality, size and format do to a file and a picture
Question
What do quality, size and format change about an image file, and what do they cost the picture? Re-encode a picture in your browser, read the real byte counts, slide between before and after, look at the difference and sweep the quality. It is a teaching bench, not a compressor; the image never leaves your browser.
Bench
The file is read by this tab and never uploaded. JPEG, PNG, WebP, GIF or BMP up to 20 MB and 36 megapixels, as far as your browser can decode them.
PNG has no quality setting: it keeps every pixel, so only the size changes the result.
JPEG has no transparency: transparent areas are drawn on white.
Choose an image, or use the sample picture, then change the settings.
| Result | original | output |
|---|---|---|
| File size (measured) | — | — |
| Dimensions (measured) | — | — |
| Compared with the original (measured) | — | — |
| Uncompressed size per encoded byte (theoretical) | — | — |
| Uncompressed pixels (theoretical) | — | — |
The difference view shows how far each pixel moved, amplified 8 times. Black means identical. It compares at the output size.
Each row is a real encode in this browser. On photos the curve is steep at the top: the last quality points cost the most bytes.
What to watch
- lossy and lossless
- JPEG and WebP (here) discard detail the eye notices least, and quality sets how much. PNG keeps every pixel exactly, so it only shrinks by finding patterns, which works well on flat graphics and poorly on photos.
- re-encoding
- Every lossy save starts from decoded pixels and throws away more. Saving a JPEG as JPEG again is not free, and the artifacts of the first save are now part of the picture.
- resizing
- Fewer pixels usually shrink the file whatever the format, and the loss is blurriness, not blocks. Resize only and quality are two different dials; compare the “small preview” and “resize only” presets.
- artifacts
- At low quality look for blocks along edges, ringing (halos) around the sharp disc and square, smeared fine stripes and banding in the smooth gradient. The difference view makes them visible.
- measured, not promised
- Byte counts come from the file this browser’s encoder produced. They differ between browsers and versions, so the same settings can give different sizes elsewhere. No target size can be guaranteed from a quality setting; this page does not try.
Limits
- This is a teaching experiment, not a compression tool. It does not try to hit a size and does not produce a download.
- It uses your browser’s own encoders (canvas). Mochifile’s engine uses its own codecs so results match across browsers; the numbers here will not match it.
- WebP encoding is missing in some browsers; the page detects it and says so instead of showing a PNG as WebP. GIF and BMP can be read but are not offered as outputs.
- The pixel size is read from the file header and anything over 36 megapixels (or whose header cannot be read in the first 256 KiB) is refused before decoding. AVIF is not accepted because its size cannot be checked that way. Animated GIFs use their first frame. EXIF orientation is applied; other metadata and color profiles are not kept.
- Some browsers (notably Safari) limit canvas size, so a very large image may fail to encode at full size, and browsers that protect against fingerprinting add noise to canvas readback, which would show up in the difference view. Zoom magnifies the centre only.
- Everything stays in this tab: no upload, no storage, no download. Previews are drawn on canvases and the decoded image is released when you pick another one or leave the page.
Fidelity
Inspired by the problem Mochifile solves, not by its interface or engine: Mochifile ships its own codecs so results match across browsers, while this page uses your browser’s encoders, so numbers differ. Revision f674bf1 is the Mochifile state read for its image-engine notes. Byte counts are measured; pixel sizes are labeled theoretical.