How to compress images for the web (without ruining them)

On most websites, images are the largest single contributor to page weight — commonly 50% or more of what a visitor downloads before they see anything meaningful. That makes image compression the highest-leverage performance work available: halving your image bytes often cuts total page weight by a quarter or more, improving Largest Contentful Paint, reducing mobile data cost, and lowering bounce rates that climb with every extra second of load time.

Unlike refactoring JavaScript or redesigning your server architecture, compressing images requires no code changes and no infrastructure. You can do it today, on files you already own, with tools that run in your browser. The rest of this guide gives you concrete targets, the lossy-versus-lossless decision, and a workflow you can repeat every time you publish.

Lossless compression shrinks a file without discarding any data — the decoded image is bit-for-bit identical to the original, and PNG and lossless WEBP work this way. It is the right mode for logos, screenshots, diagrams, and anything where a single altered pixel on text or a hard edge would be visible. The size reduction is modest — often 10–40% — because the data must remain recoverable.

Lossy compression discards information judged imperceptible to human vision, guided by a quality setting. This is where the dramatic savings live: quality-85 JPEG or WEBP images are typically 60–90% smaller than a PNG of the same photo with no visible difference at normal viewing size. The rule of thumb that holds up in practice: use lossy for anything photographic, quality 80–90, and look at the result at 100% zoom before you commit.

• Lossless: graphics, text, screenshots — safe but modest savings
• Lossy: photos and complex imagery — huge savings at quality 85+
• Always compress from the highest-quality original you have
• Never re-compress an already-compressed file more than once

Abstract advice is useless without numbers, so here are working targets for common web image roles. Hero and banner images (the large image at the top of a page): aim for 100–200 KB in WEBP or AVIF; if yours is over 300 KB, it is a candidate for resizing as well as compressing. Content and blog images inline in an article: 50–150 KB. Product or gallery photos: 40–100 KB each, since galleries multiply weight quickly.

Thumbnails and card previews: 10–30 KB — these render small, so aggressive compression is invisible. Background or decorative images: compress hardest, 50–150 KB, since they are often large in dimensions but low in visual importance. Icons and logos: under 20 KB in PNG is normal; if yours is larger, it probably carries embedded raster sizes you do not need. A useful audit exercise: run your heaviest page through a performance tool, list the top ten images by bytes, and fix them in descending order. The first three usually account for most of the problem.

Compression squeezes the encoding; resizing removes data you never needed in the first place, and it is almost always the bigger win. If your layout renders an image at 800 pixels wide but you uploaded the 4000-pixel camera original, the browser downloads roughly 25 times the pixels it can display. Downsampling to 1.5–2× the rendered width (to stay sharp on high-density screens) before compression routinely cuts weight by 70–90%.

Watch the retina math: a 600-pixel-wide slot on a modern phone benefits from a 1200-pixel source, so do not simply match CSS pixels — double for high-DPI displays. Also strip metadata (EXIF, GPS, camera settings) while you are at it; most modern compression pipelines remove it by default, and it is pure bytes for web delivery — though keep the original files in storage if the photo records matter to you.

Compression and format choice are the same conversation. Converting a PNG screenshot of a photograph into lossy WEBP beats any amount of PNG-level tuning; converting a logo from JPG to PNG fixes transparency and usually shrinks it. The format decision tree stays simple: photographs go to JPG or WEBP, graphics with transparency go to PNG or WEBP, and modern web delivery defaults to WEBP (or AVIF with a fallback) when your audience is on current browsers.

Animated content deserves its own note: GIF caps at 256 colors and wastes bytes on every frame. WEBP and AVIF both animate — converting a typical GIF to animated WEBP often halves the size with better color. For hero images specifically, modern formats matter more because they are the largest files on the page: the same photograph at 180 KB as JPEG might be 120 KB as WEBP and 80 KB as AVIF.

Workflows beat one-off decisions, because images keep arriving. This five-step routine takes a minute per image once it is habit, and it produces consistent results across a whole site.

1. Start from the original or highest-quality export — never from a file that already passed through a messenger or social app.
2. Resize to 1.5–2× the rendered width (2× for full-width heroes and anything shown on retina screens).
3. Pick the format: JPG/WEBP for photos, PNG for graphics with transparency, WEBP or AVIF for everything a modern browser will read.
4. Compress at quality 85 to start; inspect at 100% zoom, then dial down (75–80) if the file still exceeds your target, or up (90–95) if detail visibly suffers.
5. Verify the result on the actual page — at real size, on a real connection profile — and keep the original archived for future re-exports.

The ConvertKit image studio compresses files entirely on your device: drop in up to 20 images at once, set a target quality (or a target file size), preview before and after side by side, and download the batch as a ZIP. Nothing is uploaded, so client work, unreleased products, and personal photos stay private, and conversion speed depends only on your hardware rather than your connection.

1. Open the image studio and drop your files into the drop zone — PNG, JPG, WEBP, HEIC, AVIF, BMP, GIF, and TIFF are all accepted.
2. Choose Compress and set the quality slider; 85 is the sweet spot for photographs, 95+ for graphics with fine text.
3. Use the live preview to compare against the original, and check the reported file size against your target.
4. Download the compressed files individually or as a batch ZIP — then swap them into your site or document.

Compression without measurement is guesswork. Before you start, note the page weight of your heaviest page (a performance audit tool will list it). After replacing images, re-run the same audit and compare: total bytes, Largest Contentful Paint, and the individual image entries. A well-executed pass on an image-heavy page typically cuts 40–70% of image weight with zero visible layout change.

Also check the things numbers miss. Open each compressed image at 100% zoom and look at text edges, faces, and gradients — the three places lossy artifacts appear first. Click through the page on a phone-width viewport to catch images that now render blurry because you resized too aggressively. If both checks pass and the bytes dropped, the work is done; you can apply the same targets to every future upload.