Dragging a quality slider from 100 down to 80 and eyeballing the result is how most people pick a JPG quality setting, and it works fine until you need to explain why one image looks fine at 40 and another falls apart at 70. The quality number isn't a percentage of "how much detail is kept" — it's an index into a quantization table, and how much damage a given quantization level does depends entirely on what's in the image.
What the Quality Slider Actually Controls
JPEG encoding splits an image into 8x8 pixel blocks, runs each block through a discrete cosine transform, and then quantizes (rounds down) the resulting frequency coefficients. The quality setting scales the quantization table: higher quality means finer rounding steps and more preserved high-frequency detail, lower quality means coarser rounding and more coefficients zeroed out entirely.
This is why quality isn't linear in its effect on file size. Going from 100 to 90 often barely changes the file at all, because the top of the quality range mostly discards frequency information that was already close to imperceptible. Going from 60 to 50 can cut file size dramatically because you're now zeroing out coefficients that carry real, visible structure. The steepest size drop per quality point usually happens in the 50-75 range — which is also where artifacts start becoming visible if you push too far.
Chroma Subsampling Matters More Than the Number
Most encoders bundle a second lossy decision into the quality setting: chroma subsampling. At 4:2:0 subsampling, color resolution is quartered relative to luminance, because the human eye is far more sensitive to brightness changes than color changes. This is nearly free for photos of natural scenes but visibly destructive for content with sharp color edges — text on a solid background, flat-color illustrations, or UI screenshots with thin colored borders.
If you're compressing a photo, 4:2:0 subsampling at quality 75-85 is usually indistinguishable from the source. If you're compressing a screenshot or a graphic with text, either keep subsampling at 4:4:4 (no chroma reduction) or skip JPG entirely — PNG or WebP will both compress and look better for that content type.
A Practical Workflow, Not a Fixed Number
Instead of memorizing "use quality 80," treat quality selection as a search with three checkpoints:
- Start at 85 as a safe baseline for photographic content.
- Drop in increments of 10 while zooming to 100% on the busiest region of the image — faces, text edges, high-contrast boundaries. Blocking artifacts (visible 8x8 grid patterns) and color banding in gradients are the first failure signs.
- Stop one step above the first visible artifact, not at the exact point artifacts appear — compression artifacts often become more visible after re-encoding through a CDN or after the image is displayed at a slightly different size than you tested.
// Example: batch-testing quality levels with sharp (Node.js)
const sharp = require('sharp');
async function testQualityLevels(inputPath, levels = [60, 70, 80, 90]) {
for (const quality of levels) {
const buffer = await sharp(inputPath)
.jpeg({ quality, chromaSubsampling: '4:2:0', mozjpeg: true })
.toBuffer();
console.log(`quality=${quality} -> ${buffer.length} bytes`);
}
}
Note the mozjpeg: true flag — MozJPEG's encoder produces noticeably smaller files than baseline libjpeg at the same visual quality, mostly through better default Huffman tables and trellis quantization. If your pipeline supports it, switching encoders is a free size reduction with no quality tradeoff decision required.
When File Size Matters More Than the Quality Number
For most web use cases you don't actually care what the quality number is — you care about hitting a target file size or a target visual bar. Two situations call for different strategies:
Target file size (e.g., under 100KB for a hero image): binary-search the quality parameter against actual output size rather than picking a fixed number, since content complexity swings file size at a given quality by a wide margin between images.
Target visual bar (e.g., "must survive a print catalog crop"): fix quality high (90+) and instead reduce dimensions, since downscaling reduces file size with far less perceptual damage than aggressive quantization at full resolution.
Resizing before compressing is underused. A 4000px source image compressed at quality 60 to fit a 1200px display slot will almost always look worse and weigh more than the same source resized to 1200px first and then compressed at quality 80. If your images arrive from a CMS or camera at full resolution, run them through an image resizer before you touch the quality slider at all — you're solving two different problems with one lever otherwise.
JPG vs. Reaching for a Different Format
Quality tuning has a ceiling. If you've pushed quality down to the edge of visible artifacts and the file is still too large, that's usually a sign JPEG isn't the right codec for the content, not that you need to compress harder. Flat-color graphics, screenshots, and images needing transparency belong in PNG or WebP. Photographic content that still needs a smaller footprint than JPEG can deliver is a candidate for WebP or AVIF, both of which use more modern intra-frame prediction and generally beat JPEG at equivalent visual quality for photos.
Testing Without Guessing
The fastest way to find your actual threshold is to compress the same image at several quality levels and compare file sizes and artifacts side by side rather than trusting a single pass. Run your source images through the JPG Compressor, try a few quality levels on a representative image from your actual content — not a stock photo — and lock in the lowest setting where you can't spot artifacts at the size the image will actually be displayed.