What JPEG quality should you use? The settings that actually work

The rule

Use quality 75–85 for almost everything. Within that band, the file size is still falling sharply while the visible quality cost is essentially nil on any normal display. Below 60 you are trading visible damage for bytes; above 90 you are paying for detail no screen will show.

If you want a single number to type: 80. It is the most defensible default across JPEG, WebP and AVIF, and it is the point most professional pipelines converge on.

If you want the nuance, it is genuinely format-dependent and content-dependent — the rest of this page is the nuance, expressed as rules rather than adjectives.

Why the curve bends — the one thing to understand

Compression quality and file size do not scale together. File size falls roughly logarithmically as you lower quality, while perceptual error grows slowly and then suddenly. That mismatch is the whole game.

In practice this creates three zones:

Above ~90 — the waste zone. Files get noticeably bigger and nothing looks better. A JPEG at 95 and a JPEG at 100 are indistinguishable; the second can be twice the size. This is where the majority of unoptimized images on the web actually sit.

75 to 88 — the sweet spot. The size curve is still descending fast and the quality cost stays under the threshold of normal perception. Almost every production image belongs here.

Below ~60 — the damage zone. Error climbs steeply. Blocky artifacts appear in smooth gradients (skies, skin, studio backdrops) and along high-contrast edges. Defensible only for backgrounds and thumbnails.

On the demo image used on the home page, this is measurable rather than theoretical: the 189 KB source encodes to 112 KB at q80 (−41%) and 70 KB at q45 (−63%). Moving from q45 to q80 costs 42 KB to remove artifacts that are visible at 100% zoom. That is the tradeoff the whole question is about.

Where artifacts show up first

Quality thresholds are not universal — the same setting that is invisible on one image is obvious on another. Artifacts are a function of detail and smoothness, and they appear earliest in a predictable order:

1. Smooth gradients. Skies, studio backdrops, fog and skin tones. There is no high-frequency detail to hide the error in, so banding and blotching appear immediately. If an image is mostly gradient, be careful below 70.

2. Fine repeating texture. Foliage, hair, fabric weave, brick, gravel. The encoder discards exactly the detail your eye uses to recognise texture, and it does so before it discards anything else.

3. Text and hard edges. Screenshots, charts, diagrams, UI captures. JPEG is structurally the wrong format for these — ringing around glyphs is unavoidable at low quality. Use PNG or WebP-lossless instead.

4. Saturated colour. Highly saturated reds and oranges suffer first because chroma is subsampled. Banding on a sunset is usually chroma, not luma.

The practical consequence: compression tolerance is per-image, not per-site. A quality-80 blanket rule applied to a sky-heavy hero shot and a textured product photo will feel conservative on one and risky on the other.

Recommended settings by format

These are starting points, not laws. They assume a photograph. Adjust with the "where artifacts show" section above.

JPEG — 78 to 85. The classic range, and still correct. MozJPEG's improved encoder means you can sit at the lower end of that band than you could with a stock libjpeg encoder; roughly 10–15% smaller files at matched quality is the documented gain. Below 75 on a photographic JPEG, banding becomes a real risk.

WebP — 75 to 82. WebP's lossy mode is more efficient than JPEG, so it can go lower for the same visual result. Quality 80 in WebP is broadly comparable to quality 85 in JPEG. It also handles transparency and animation, so it is often the format that lets you stop shipping a PNG.

AVIF — 60 to 75. This surprises people. AVIF's quality scale is not calibrated to JPEG's — AVIF at 65 is frequently visually equivalent to JPEG at 80, at a smaller size. Encoding is slower, which is the real cost. If you set AVIF to 80 you are usually leaving significant savings on the table.

PNG — lossless, no quality setting. Use the maximum optimisation effort (OxiPNG and similar tools re-encode losslessly for typically 10–30% off a naive PNG export). If you are reaching for a PNG quality slider, you probably want WebP instead.

Screenshots, UI and diagrams — do not use lossy JPEG. Use PNG, or WebP in lossless mode. Text is the worst case for DCT-based compression and the artifacts are maximally visible.

Resolution matters more than quality

This is the most commonly missed point in the entire discussion. Lowering quality from 95 to 80 might cut 40% of the bytes. Resizing a 4000px image down to the 1600px it is actually displayed at can cut 80% or more — and improve sharpness.

A 4000-pixel photo rendered into a 800-pixel slot is spending bytes on pixels nobody will ever see. Browsers have to download all of them and then discard three quarters of the detail during scaling. That is pure waste, and no quality setting can recover it.

The correct order of operations is therefore:

1. Resize to the largest size it will actually be displayed at (accounting for 2× retina densities — so 1600px for an 800px slot).

2. Choose the right format — AVIF or WebP for photographs, PNG or lossless for UI and text, SVG for logos and icons.

3. Only then tune quality within the bands above.

Doing these out of order is why so many "optimized" sites are still slow. A beautifully-compressed 4000px JPEG is still a slow image.

When to break the rule

Go lower (55–70) for: decorative background images behind text overlays, images displayed below the fold at small sizes, thumbnails and avatars, and photographic textures where the viewer is not inspecting detail. A 24px avatar at quality 90 is a waste of bytes.

Go higher (85–92) for: the hero or LCP image where perceived sharpness drives conversion, product photography where colour accuracy and detail sell the item, anything with fine type, and portfolio or gallery work where the image is the product.

Never go above 92 for web delivery unless you have measured a reason. The file grows measurably and nothing visible changes. If you believe you need quality 100, you are almost certainly compensating for a resolution or format problem upstream.

Go lossless for: images that will be re-edited later, anything with text or line art, and any image that will be re-compressed again downstream. Re-compressing an already-lossy image repeatedly is how sites end up with visible artifacts from a source that looked fine.

Test it on your own image

Generic advice has a ceiling, because the right answer depends on your specific image. The reliable method takes about thirty seconds:

1. Encode at 80. Then encode again at 60.

2. Open both at 100% zoom, side by side, on the display your audience actually uses.

3. Look for banding in gradients and smearing in fine texture.

4. Pick the lowest quality where you cannot see the difference without hunting for it. That is your number, and it will usually be lower than you expected.

You can do this in ImageAlchemy without uploading anything: drop the image, set the quality, and use the before/after comparison slider to inspect the result at full zoom. Because processing is client-side, you can iterate as many times as you like without the image ever leaving your machine.

The short version

Default: quality 80.

By format: JPEG 78–85, WebP 75–82, AVIF 60–75, PNG lossless.

Resize before you compress. It matters more than the quality setting, every time.

Above 90 is almost always waste; below 60 is almost always visible damage.

Both panels of the tradeoff are measurable — use the quality explorer above, or test on your own image. Whatever you do, do not pick 100 "to be safe": that is how a site ends up shipping 400 KB images that could have been 90 KB with no perceptible difference.