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.

A page is a budget, and images are the line item that dominates it. The arithmetic is worth doing explicitly: a typical article page ships HTML, CSS, JavaScript, fonts, and images — and on most sites the images total more than everything else combined. If your page carries eight inline images at 300 KB each, that is 2.4 MB before anyone scrolls. On a 10 Mbps connection, raw transfer of 2.4 MB takes about two seconds; on a 1.6 Mbps mobile link it takes twelve, and real pages are slower than raw transfer math because requests queue, connections stall, and the phone is also parsing and executing JavaScript.

Working backward from a load-time goal gives your targets. Suppose you want the page fully transferred in three seconds on a modest mobile connection — call it 3 Mbps effective, or roughly 375 KB per second. That caps total page weight around 1.1 MB, and if images should consume half of it, your entire image budget for the page is about 550 KB. Suddenly the difference between a 90 KB and a 300 KB hero matters enormously, and the 25 KB thumbnails are not micro-optimizations — they are what keeps the budget honest across a long article.

This reframing is useful because it replaces adjectives with numbers. "Optimize your images" produces anxiety; "this page has 550 KB of image budget and these three files eat 700 KB of it" produces a work list, ordered by size, that you can clear in an afternoon. Revisit the arithmetic whenever the layout changes — a page that gains a full-bleed hero has spent its budget before the first paragraph is read.

Even perfect compression leaves a trap: serving the same bytes to every device and every scroll position. Three levers work together, and teams that pull only the compression lever leave most of the win on the table.

Responsive sizing tells the browser to download the image at the size the viewport actually needs. The standard mechanism is srcset with width descriptors plus a sizes attribute: a phone fetches a 400-pixel variant while a desktop fetches the 1600-pixel one, and the savings multiply across the page. Modern alternatives — CSS background images for decorative art, container queries for component-scoped media — follow the same principle: one source per slot is wasteful when slots differ by four times.

Lazy loading defers images below the fold until the reader scrolls near them. The browser attribute loading="lazy" is one line and does most of the work; the discipline that makes it correct is marking the image the reader sees first (the LCP candidate) as eager with fetchpriority="high", because lazy-loading your own hero is a self-inflicted performance wound. And format selection completes the trio: serve AVIF or WEBP to browsers that accept them — content negotiation or a CDN transform does this — while keeping JPEG for stragglers.

In practice: compression sets the floor (each delivered byte is as small as it can be without visible loss), responsive sizing ensures you deliver few bytes in the first place, and lazy loading sequences them behind the content the reader came for. Do them in that order — compress first so every subsequent lever multiplies a smaller number, then size, then defer.

• Compression: every delivered byte earns its place
• srcset + sizes: deliver viewport-appropriate pixels, not camera-original ones
• loading="lazy" below the fold; fetchpriority="high" on the hero image
• Modern formats via content negotiation, with JPEG as the universal fallback

A single global quality number is convenient and slightly wrong, because artifact visibility depends on what the picture contains. The content itself tells you where to set the slider, and the categories below cover nearly everything a website ships.

Portraits and people: faces are where viewers detect damage first, so stay at quality 85–90 and inspect skin tones and hair at 100% zoom. Text, logos, and UI screenshots: push to 95 or export lossless PNG — ringing around glyphs is visible long before general blur is, and screenshots are often flat enough that lossless costs little. Smooth gradients and night skies: watch for banding; if it appears, raise quality or switch the target format (AVIF and WEBP band later than JPEG at equal settings).

Busy texture — foliage, gravel, crowds, fabric: masks compression brilliantly, so these tolerate the bottom of the normal range, 75–80, with confidence. Flat-color illustration and logos on solid backgrounds compress so efficiently that raising quality barely costs bytes; when the file is already under target, spend the headroom on fidelity. And noisy or deliberately grainy images: noise is expensive to encode, so either accept quality in the 80s or denoise at export — but know that grain is the first thing low bitrates erase, which may or may not matter to the look you wanted.

One caution about iterating: every re-export of a lossy file stacks artifacts (the format guide covers this in depth). Set the quality once, from the original, rather than nudging a file down one notch at a time through five exports — the fifth version at "quality 85" is not the same as the first.

Compression work only pays off if the optimized bytes are what actually reach the reader, and that depends on how the image is served. The simple version: compress and resize at publish time, upload the finished file, and let caching do the rest. The browser fetches it once, stores it, and subsequent page views cost nothing — the visitor’s second visit is faster than their first purely because of headers you set once.

The modern version adds variants. Most sites now emit an image into two or three formats (AVIF, WEBP, JPEG) and one or two widths each, letting the browser pick the best file it understands at the resolution it needs. That sounds like a combinatorial mess, but it collapses into two rules: decide the variant set at publish time (never per request), and give every variant a stable, content-addressed URL so caches never see a different image under the same name. When the source changes, the URL changes — a version parameter, a hash in the filename, whatever your hosting supports — and caches roll forward cleanly instead of serving last month’s hero next to this month’s copy.

What to avoid is per-request transcoding without caching: services that re-compress on every hit burn CPU to produce identical bytes while caching that never engages, and dynamic URLs behind query strings that change per visitor defeat browser caches entirely. Run the pipeline once per image version, cache the outputs at the edge and in the browser, and spend your performance budget on the images that have not been optimized yet — not on re-optimizing the ones that already are.