Best Image Compression Settings for Web

Good compression settings are boring in the best way: they produce small files that nobody notices. The trick is to set dimensions, format, quality, and metadata together instead of treating quality as the only control.

Default settings for most sites

Start from these in the batch image compressor, then adjust only when an image fails visual review.

Settings by use case

Size budgets

Use a size budget when the destination has a real limit:

• Under 100 KB for small article images
• Under 200 KB for Open Graph previews
• Under 300 KB for important mobile heroes
• Under 500 KB for rich product zoom images

Size-budget encoding searches for the highest quality that fits the byte target. It is better than guessing quality numbers over and over.

What to avoid

• Quality 100 for web delivery
• Serving 4000px camera originals
• Compressing an already compressed export repeatedly
• Using PNG for large photos
• Lazy-loading the LCP hero image

Build presets by content type

The best teams do not choose settings from scratch for every upload. They create a few presets and use them consistently. That keeps image quality predictable and makes it much easier to train writers, merchants, or developers who are not image specialists.

For a content site, you might use:

For ecommerce, add product-specific presets: product zoom, product grid, collection banner, and marketplace export. Those images serve different jobs, so they deserve different settings.

How to tune without damaging quality

Change one variable at a time. If an image is too large, reduce dimensions first. If it is still too large, switch format. If it is still too large, lower quality in small steps. Jumping from JPEG 92 to JPEG 60 may hit the byte target, but it also makes it hard to know what actually fixed the file size.

Use visual review checkpoints:

• Skin tones should not become waxy.
• Product textures should remain believable.
• Text in screenshots should stay crisp.
• Gradients should not show banding.
• Dark shadows should not turn into blocks.

If only one image in a batch looks bad, override it. Presets are defaults, not handcuffs.

Metadata and privacy settings

For public web images, strip metadata unless you have a specific reason not to. EXIF can include GPS coordinates, camera serials, timestamps, and editing software. Removing it usually saves a little file size and avoids accidental privacy leaks.

Do keep orientation handling. A pipeline should rotate the image correctly before stripping metadata so the published image does not appear sideways in some browsers or CMS previews.

What about retina screens?

High-density displays do not mean you should upload enormous originals. A 720px-wide image in an article column may need a 1440px candidate for sharpness on 2x screens, but it does not need the full 4032px camera file. Responsive images let you serve the right candidate without punishing every visitor.

For important layouts, export a small set of widths: 480, 960, 1440 for article images; 960, 1600, 2200 for heroes. Then use srcset and sizes so the browser can choose intelligently.

When byte budgets matter

Byte budgets are useful when you have a performance target, a CMS limit, or a social crawler that times out on huge images. They are less useful when they become arbitrary rules. A 280KB hero that looks excellent and loads early can be better than a 95KB hero that makes the brand look cheap.

Use budgets as guardrails: under 100KB for small inline images, under 200KB for social previews, and a few hundred KB for major LCP images where quality matters.

For format decisions, read JPEG vs PNG vs WebP vs AVIF. For LCP-specific tuning, read how images affect LCP.