Why image file size matters for the web
Images are usually the heaviest thing on a web page. A single uncompressed hero photo straight off a modern phone or camera can weigh 4MB or more. Multiply that by a handful of images on one page, and you've got a page that takes seconds longer to load than it needs to.
That delay isn't just annoying, it's measurable. Largest Contentful Paint (LCP), one of Google's Core Web Vitals, specifically measures how long it takes the biggest visible element (very often an image) to render. Slow LCP hurts both user experience and search ranking.
It also costs your visitors real money and battery. Mobile data isn't free or unlimited for everyone, and a page full of oversized photos burns through both faster than it should. A 4MB hero image isn't a minor inefficiency, it's a real, fixable problem.
There's a compounding effect too. Search engines and social platforms often generate their own previews and thumbnails from your source images, and a bloated original slows down every one of those downstream processes. Shrinking the file at the source fixes the problem everywhere it would otherwise show up, instead of just on the one page you happened to notice was slow.
How JPEG compression actually works
JPEG is a lossy format, meaning the encoder deliberately throws away some pixel data to shrink the file. It targets the specific kinds of detail the human eye is worst at noticing, subtle color shifts and fine texture, rather than removing information at random.
That's why quality settings work the way they do. A JPEG saved at 100% quality keeps almost everything. Drop that to somewhere between 60% and 80%, and in most cases the image looks identical at normal viewing size, while the file shrinks by 50-80%. You're not really losing quality you can see, you're losing quality you can't.
Push the setting too far down, though, and the losses stop being invisible. That's where things like visible blocky patches and color banding start to appear.
This is also why the same photo compressed at the same setting can produce very different file sizes depending on its content. A busy, detailed photo of a forest has plenty of texture for the encoder to approximate without anyone noticing. A photo with large smooth areas, like a clear sky or a plain wall, has less to hide behind, so artifacts in those flat regions tend to show up sooner.
Finding the right quality setting
For most photographs intended for the web, the sweet spot is 70-85% quality. Inside that range, compression artifacts are essentially undetectable to the naked eye, while the file size drop is substantial.
- Above 85%. You're paying in file size for quality gains nobody will notice.
- 70-85%. The sweet spot for photos. Small file, no visible difference.
- Below 60%. Artifacts start becoming visible, especially blockiness around sharp edges and fuzziness around text or fine lines.
Photos with lots of flat color or sharp geometric edges (screenshots, graphics, text-heavy images) show compression artifacts sooner than busy, detailed photographs do. If an image looks slightly "off" after compressing, that's usually the first place to look.
A useful rule of thumb: start around 80% quality, then only drop lower if the file still needs to be smaller and you've confirmed the result still looks clean at full size.
Resizing vs compressing
Quality reduction and resizing are two different levers, and people often reach for only one of them. Resizing reduces the actual pixel dimensions of the image. Compressing keeps the same dimensions but reduces how precisely each pixel is stored.
If an image is going to be displayed at, say, 800 pixels wide but the original file is 4000 pixels wide, resizing it down does far more for file size than tweaking the quality slider ever will. You're removing pixel data the browser was never going to show in the first place.
The best results almost always come from doing both: resize the image to the dimensions it will actually be displayed at, then apply a sensible quality setting on top of that.
A quick way to check if resizing is worth doing: look at the display size of the image on the page versus its actual pixel dimensions. If a photo shows up in a 600-pixel-wide card but the file itself is 3000 pixels wide, you're shipping five times more pixel data than anyone will ever see. No amount of quality-slider tweaking recovers that waste as effectively as simply resizing down to something closer to the display size, ideally with a small buffer for higher-resolution screens.
Compressing images for free, without uploading them anywhere
You don't need design software or a paid subscription to compress images properly. Our own free image compressor runs entirely in your browser using the Canvas API, so your photo never leaves your device. There's no sign-up and no upload step.
It shows a live before-and-after file size comparison as you move an adjustable quality slider, so you can see exactly how much you're saving before you download anything. That makes it easy to find the lowest file size that still looks right, rather than guessing.
Because everything happens locally, there's no waiting on an upload, no file size limit imposed by someone else's server, and no risk of a photo you'd rather keep private sitting on a third party's storage, even briefly. That matters for anything from product photography to personal photos you're preparing to share.
Common mistakes
- Re-compressing an already-compressed JPEG repeatedly. Every re-save re-applies lossy compression on top of the last one. Each round trip loses a little more quality, even at the same setting.
- Forgetting to resize oversized photos before compressing. Cranking down the quality slider on a 4000-pixel-wide image displayed at 800 pixels wastes effort. Resize first.
- Using PNG for photos. PNG's lossless compression bloats photo file sizes for no visible benefit. Save PNG for graphics with flat color and sharp edges, and use JPEG for photographs.