Everyone has a number they trust. 80, or 85, or 90 for the careful. Almost nobody can say what the number is a number of, which is why the same photograph saved at 90 in one program and 90 in another can differ by half a megabyte. The slider is real and it is worth understanding, because once you know what it moves you can tell in advance which images will shrink and which ones will fall apart.
Quality Is a Multiplier on a Table
JPEG, standardised as ITU-T T.81 in 1992, does not store pixels. It splits each channel into 8×8 blocks, runs a discrete cosine transform over each one, and ends up with 64 coefficients describing that block as a mix of frequencies: flat tone first, progressively finer ripples after it. Nothing has been lost yet — the transform is reversible.
The loss happens in the next step. Each coefficient is divided by a number from a quantization table and rounded. Large divisors on the high-frequency coefficients round most of them to zero, and long runs of zeros are what the entropy coder compresses so effectively. Annex K of the standard prints a pair of example tables, one for brightness and one for colour, and they are the ancestors of nearly every table in use.
The quality slider scales those tables. The formula in libjpeg, which most of the world's JPEGs have passed through, is exactly this: for a quality below 50 the scale factor is 5000 / quality, and from 50 upwards it is 200 - 2 × quality. Each table entry is multiplied by that factor, divided by 100, and clamped between 1 and 255.
Run the numbers and the slider stops being mysterious. Quality 50 leaves the tables exactly as the standard prints them. Quality 80 scales them to 40 percent, so the divisors are less than half as aggressive. Quality 90 gets to 20 percent, quality 100 drives every entry to 1 and quantizes nothing at all. The scale is not linear and it was never meant to be a percentage of the image.
What the Numbers Mean in Practice
Scale factor from the libjpeg formula. File sizes are for a typical 12-megapixel photograph and move a long way with subject matter.
| Quality | Table scale | What you get |
|---|---|---|
| 100 | 0% | No quantization. Enormous files, no visible gain over 95 |
| 95 | 10% | Archival. Use when the file will be edited and saved again |
| 85 | 30% | Print and portfolio work; artefacts need a loupe |
| 80 | 40% | The default almost every guide lands on. Roughly half of 95 |
| 70 | 60% | Fine for a feed or a thumbnail, visible on flat gradients |
| 50 | 100% | The tables as standardised. Blocking is obvious on skies |
| 30 | 167% | Only when a byte limit leaves no choice |
Half the loss has nothing to do with quality
Before any of this, the encoder converts RGB to luma plus two chroma channels and usually throws away three quarters of the chroma — 4:2:0 subsampling, one colour sample per 2×2 block. It works because human vision resolves brightness detail far better than colour detail, and it is free on a photograph. It is not free on saturated text, a red logo on black, or a thin coloured line, all of which come out smeared no matter how high you push the slider. Many encoders switch to 4:4:4 above quality 90; libjpeg's own default does not unless it is told to.
Why Re-Saving Is Worse Than Saving Low
A JPEG opened and saved again is not compressed once, it is compressed twice, and the second pass is applied to the artefacts of the first rather than to the photograph. The blocking of generation one becomes real detail the encoder now has to spend bits describing, which is the mechanism behind every image that has visibly rotted from being reposted.
The usual claim that JPEG degrades on every save needs one correction. If nothing changes — same encoder, same quality, same subsampling, no crop, no resize — the second save is close to idempotent, because the coefficients are already sitting on the quantization grid and land in the same buckets. Drift continues through colour conversion rounding, but slowly.
What restarts the damage in earnest is any change at all: a different quality, a resize, a rotation that is not a multiple of 90 degrees, a switch of subsampling, a different encoder. Each shifts the coefficients off the grid, and they are re-rounded from scratch.
The practical rule follows directly. Keep the original and compress from it every time. One save at 75 from the source beats three saves at 90 from each other, and it is smaller.
See what a quality setting costs before you keep it
Compress by quality or to an exact size in KB, then check the result against the original at 1:1.
The Decisions That Move More Bytes Than the Slider
Quality is the control everyone reaches for. These usually matter more.
Resize first, and it is not close
File size tracks pixel count, so halving both sides removes three quarters of the pixels before a single quality decision is made. A 4032-pixel phone photo displayed in a 800-pixel column is paying for detail that is discarded on arrival.
Match the format to the content
Photographs to JPEG or WebP; logos, screenshots and line art to PNG or SVG. A screenshot of text through a JPEG encoder gets ringing around every letter, and a photograph through a PNG encoder comes out several times larger for no visible gain.
Strip the metadata
A camera JPEG can carry tens of kilobytes of EXIF, colour profile and an embedded preview thumbnail. Anything that re-encodes through a canvas drops all of it, which is a small saving and a large privacy one, since GPS coordinates live in there.
Noise is expensive
Grain, film emulation and high-ISO speckle are high-frequency detail by definition, which is exactly what the encoder spends the most bits on. A slight noise reduction before compressing often saves more than dropping ten points of quality.
Serve the size you display
`srcset` exists so a phone downloads a phone-sized file. Compressing one giant image well is still worse than sending the right one.
What a Browser Can Actually Encode
A page can write three formats and no others: JPEG, PNG and WebP, through canvas.toBlob. The quality argument applies to the first and the third and is ignored for PNG.
WebP is the one worth switching to. Google's own comparison against a corpus of JPEGs puts it 25 to 34 percent smaller at equivalent SSIM, and its lossless mode about 26 percent smaller than PNG. It also carries an alpha channel, which JPEG has never had, so it is the only format on that list that can replace a transparent PNG and still shrink it. Every browser released since 2020 displays it.
AVIF beats both, often by another 20 percent, and no browser exposes an AVIF encoder to a canvas. That is why no page-based compressor offers it, and why the last few percent still belong to a build step with sharp, cjpeg or avifenc behind it.
One more limit worth knowing: the encoders are the browser's own. A JPEG written by a canvas at quality 80 is not byte-identical to one MozJPEG writes at 80, and is usually a little larger, because MozJPEG tunes its tables and trellis-quantizes on top of them.
PNG Has No Quality Dial, and That Is the Whole Problem
PNG is lossless. Every pixel comes back exactly as it went in, which is the point for a logo and an obstacle for a compressor. There is no table to scale, no coefficient to round, and passing 0.8 to toBlob for a PNG does nothing whatsoever.
Real PNG optimizers work on the two things a canvas does not expose. Palette reduction, as pngquant does it, maps millions of colours down to 256 chosen ones and stores one byte per pixel instead of four — typically a 60 to 70 percent saving, and lossy despite the format's reputation. Filter and stream tuning, as oxipng and zopflipng do it, tries every per-row filter and a harder deflate, which is genuinely lossless and worth another 10 to 20 percent.
A browser canvas does neither. It writes 8-bit RGBA at fixed settings, so re-encoding an already optimized PNG through one reliably produces a file the same size or larger. This site's compressor treats that as a result rather than a failure: when the encode cannot beat the file you supplied, your original bytes are what you get back, and the card says so. For a PNG that genuinely needs to be smaller, the answer is usually not a better PNG, it is WebP.
Frequently Asked Questions
Related Tools
Keep Reading
Why Resized Images Come Out Noisy, and the Fix Nobody Applies
Bilinear sampling reads four pixels no matter how far you shrink, so a 20:1 reduction ignores 396 of every 400. Halving in steps reads all of them.
Rounded Image Corners: When to Use CSS and When to Bake Them In
border-radius is ignored by Outlook and dropped by most PDF exporters. Where a permanent round is the only option, and why the file must be PNG.
Base64 Images: The 33% Overhead Explained, and When It's Worth It
A base64 image is a third larger than the file, never cached on its own, and often silently dropped by the email client you were embedding it for.