Your images are probably way too big

I'm just going to say it: most images on the web are 3-10x larger than they need to be. I was helping a friend figure out why their portfolio site took forever to load last month, and I kid you not — they had a contact page background that was an 8MB PNG. A contact page. The image was a blurred gradient that could've been 40KB as a WebP.

This isn't unusual. If you've ever exported a photo from Lightroom or grabbed an image from a stock photo site and dropped it straight into your project, you're probably serving files that are massively oversized. And it matters more than you'd think. Google factors page speed into rankings. Mobile users on spotty connections will just leave. Every extra megabyte is money — both in hosting bandwidth and lost conversions.

The good news is that shrinking images without visible quality loss is genuinely easy once you know what actually moves the needle. I've compressed probably tens of thousands of images at this point across client projects, and I keep coming back to the same handful of things that matter.

Pick the right format (this alone can cut size in half)

Format choice is the single biggest lever you have, and most people don't think about it enough. Here's how I think about it:

WebP is the default answer for almost everything on the web in 2026 (I go deeper on the WebP vs AVIF debate in a separate post). It handles photos, graphics, and transparency, and it compresses dramatically better than JPEG or PNG. Browser support has been universal for a while now. If you're still serving JPEGs to the web and haven't switched to WebP, that's the lowest-hanging fruit you'll find. I regularly see 40-60% size reductions just from converting JPEG to WebP at the same visual quality.

AVIF is the newer format based on the AV1 video codec and it compresses even better than WebP — sometimes 20-30% smaller. The catch is it's slower to encode (noticeably slower for batch work) and browser support, while good, still isn't quite as universal. I use AVIF when I'm optimizing a site where performance really matters and I can provide a WebP fallback. For a quick blog post image? WebP is fine, don't overthink it.

JPEG still has its place. It's the most compatible format on earth, and modern JPEG encoders like MozJPEG squeeze out surprisingly good results. If you need maximum compatibility or you're dealing with a system that doesn't accept WebP, a well-compressed JPEG is totally respectable.

PNG is for when you need lossless quality or sharp transparency — logos, screenshots, UI elements. But please don't use PNG for photographs. I see this constantly. A 4000x3000 photo of a sunset saved as PNG will be like 15MB. That same image as a quality-80 WebP? Maybe 200KB. It's not even close.

Quality settings: where most people go wrong

Here's an opinion that might be controversial but really shouldn't be: quality 80 is almost always fine. For WebP and JPEG alike, somewhere in the 75-85 range gives you a file that's dramatically smaller than quality 95+ but looks identical to most humans on most screens.

I'll be more specific. At quality 95, you're keeping detail that literally nobody will notice unless they're zooming in to 400% and pixel-peeping. At quality 80, you've thrown away the stuff that doesn't matter and kept everything that does. The file size difference between those two settings is often 2-3x.

The one exception is if you're working with images that will be edited further downstream. In that case, sure, keep quality high to avoid generational loss. But for final output — stuff going on a website, into an app, into an email — drop that quality slider down and don't feel bad about it.

I use CanYouSmoosh for this because I can see the before/after preview while adjusting the quality slider. It's genuinely hard to spot the difference at quality 80 for most photos, but being able to confirm that visually before committing is reassuring.

Resize before you compress

This one drives me a little crazy because it's so obvious but so often skipped. If your layout displays an image at 800px wide, do not serve a 4000px wide original. The browser will download the full file and then scale it down, which wastes bandwidth and slows rendering.

I was optimizing product photos for an e-commerce client a while back, and their product cards displayed images at 400x400 pixels. The source images were 4800x4800 straight from the photographer. Each image was around 3MB. After resizing to 800x800 (2x for retina) and compressing to WebP at quality 80, they were about 35KB each. The product listing page went from loading 45MB of images to under 600KB. Same visual result.

A good rule of thumb: serve images at 2x the display size for retina screens, and no more. So if your hero image displays at 1200px wide, export it at 2400px wide. That's plenty.

Strip the metadata

Digital photos carry a surprising amount of metadata — EXIF data with camera settings, GPS coordinates, color profiles, thumbnail previews, sometimes even edit history. This metadata can add 50-200KB to a file, sometimes more.

For web use, you almost never need any of it. Strip it all out. Most compression tools do this automatically. Beyond the size savings, there's a privacy angle too — you probably don't want to publish the GPS coordinates of where a photo was taken.

Batch processing saves your sanity

Doing all of this one image at a time is fine for a hero image or a social media preview. But if you're dealing with a product catalog, a blog with lots of photos, or a site redesign where you need to re-export everything — you need batch processing.

I used to cobble together shell scripts with ImageMagick or cwebp for this (I wrote a whole batch image compression guide if you want the details), and honestly it worked, but it was a pain to set up and tweak settings. These days I just throw a folder of images at CanYouSmoosh and let it handle the batch. Pick your format, set your quality, choose a resize preset, hit go. It's the kind of thing that should be simple, and it finally is.

What actually matters (the short version)

After years of doing this, here's what I've landed on as my default workflow for web images:

Convert to WebP. Set quality to 80. Resize to no more than 2x display dimensions. Strip metadata. That's it. That gets you 80-90% of the possible size reduction with zero visible quality loss for virtually any photograph.

For graphics, logos, and screenshots, PNG through an optimizer like OxiPNG works well, or WebP lossless if you want smaller files with transparency.

For the absolute bleeding edge of compression, AVIF at quality 70-75 with a WebP fallback. But honestly, just doing WebP at 80 puts you ahead of like 90% of websites out there.

If you're building for the web specifically, my image optimization for web performance guide covers how all of this ties into Core Web Vitals and page speed.

The thing I've learned is that perfect is the enemy of good here. You don't need to agonize over whether quality 78 or 82 is better for a particular image. The difference between "unoptimized" and "reasonably optimized" is enormous. The difference between "reasonably optimized" and "perfectly optimized" is tiny. Just pick sensible defaults, apply them consistently, and move on to the stuff that actually needs your attention.