Heavy images are still one of the fastest ways to make a site feel slow. Compression shrinks file size so pages load faster, bandwidth costs drop, and mobile users on flaky networks stop bouncing. Done poorly, compression also introduces blocky artifacts, muddy gradients, and logos that look soft.
This guide helps you decide when to compress, which format fits the job, and how to choose quality settings with intent instead of guessing.
Who this is for
Bloggers, store owners, marketers, and developers who export from design tools at full resolution and need web-ready assets. Also useful for anyone attaching screenshots to docs or email who keeps hitting attachment limits.
When compression is worth it
Compress when the image will be delivered over the network or stored at scale: website heroes, product galleries, social previews, email newsletters, and app assets. Skip aggressive compression for archival masters, print-ready files, or images you will edit again - keep a lossless original and derive web variants from it.
Also compress when dimensions are larger than display size. A 4000px-wide photo shown at 800px wastes bytes even at high JPEG quality. Resize to the largest size you actually render (accounting for 2x retina if needed), then compress.
JPEG vs PNG vs WebP in practice
JPEG excels at photographs and complex gradients. It uses lossy compression that discards detail the eye is less likely to notice. It does not support transparency. At low quality settings, you will see blockiness around sharp edges and text.
PNG is lossless and supports transparency. It is ideal for UI screenshots with text, logos with crisp edges, and graphics that need an alpha channel. PNG files can be large for photos; do not use PNG as a default for camera images on the web.
WebP often beats JPEG and PNG on size for similar visual quality and supports both lossy and lossless modes plus transparency. Browser support is broad in modern evergreen browsers. For maximum compatibility in stubborn email clients or very old browsers, keep a JPEG/PNG fallback - but for most websites in 2026, WebP is a strong default for delivery.
Target sizes that keep pages snappy
Exact budgets depend on your audience and design, but useful starting targets help you know when to stop tweaking.
- Favicons and small icons: a few KB each
- Inline content images (~800-1200px wide): often 50-150KB after good compression
- Hero images: aim under ~200-300KB when possible; larger only if the visual is the product
- Open Graph / social share images: typically under 1MB; many platforms resize aggressively anyway
- Product thumbnails: prioritize consistency and clarity over pixel-perfect fidelity
Quality settings: building intuition
Quality sliders (often 0-100) are not linear perceptual scales, and they are not comparable across tools. A “80” in one encoder is not the same as “80” in another. Train your eye: compress a representative photo, zoom to 100% on faces, text overlays, and flat color areas, then compare file sizes.
Photos usually tolerate lower quality than UI chrome. Text and sharp lines reveal artifacts first - raise quality or switch to PNG/WebP lossless for those. Gradients and skies show banding when quality drops too far; a slight increase or mild noise can hide banding better than a huge quality jump.
If two settings differ by 5% in size and look identical at display size, pick the smaller one. If you see ringing around high-contrast edges, bump quality or reduce sharpening applied before export.
A practical workflow
Keep masters in a lossless or lightly compressed archive format. Export or resize to the maximum display width you need. Run a compressor - ToolMint’s image compressor works in the browser so product shots and draft creatives need not be uploaded to an unknown server just to test quality levels. Compare side by side, then download the winner into your CMS or repo.
Automate the same settings in a build pipeline (Sharp, ImageMagick, CDN image transforms) once you have found defaults that look good for your brand photography. Manual compression is for one-offs and calibration; pipelines keep production consistent.
Pitfalls to avoid
Re-encoding an already heavy JPEG multiple times stacks generation loss. Always recompress from the master when possible. Do not upscale a small image and expect compression to “fix” blur. Watch for EXIF orientation issues after processing, and strip metadata when you do not want GPS or device info embedded in public assets.
- Compressing from a previously compressed social-media download instead of the original
- Serving 3x retina assets everywhere without responsive images
- Using PNG for large photos “because quality”
- Ignoring perceived quality on real phones in sunlight
- Forgetting lazy-loading and modern formats after you already compressed files
Responsive images still matter
Compression alone cannot fix serving a desktop hero to a phone. Use srcset or a CDN image API so devices download an appropriate width. A well-compressed 2000px image is still wasteful if the layout only needs 400px. Pair format choice (WebP/AVIF where supported) with responsive delivery for the full win.
Measure with real network throttling in DevTools occasionally. Lab scores help, but a quick check on a mid-range Android phone will tell you whether your “good enough” quality still looks intentional.
Bottom line
Good compression is resize plus format plus quality, judged at the size users actually see. Prefer WebP or well-tuned JPEG for photos, PNG or lossless WebP for sharp UI, and keep originals safe. A few deliberate passes with a browser compressor will teach you more than any generic “use 60% quality” rule.