Big image files slow down websites, blow past email attachment limits, and eat up storage on your phone. The good news: you can usually cut file size dramatically without anyone noticing a difference — you just need to know what you're actually adjusting, and where the savings stop being worth it.

That gigabyte-scale images exist isn't hyperbole, incidentally. The first photograph released by the Vera C. Rubin Observatory in 2025 runs to 5 gigapixels and 14.1 GB in a single file. And of the Andromeda mosaic Hubble assembled that same year — 2.5 billion pixels, more than 600 exposures over a decade — NASA doesn't offer the full version at all: the cut-down one already passes 700 MB. If you've landed here wanting to compress something, it's almost certainly neither of those two.

Lossy vs lossless, in plain terms

Most compression works one of two ways:

Lossy (JPG, WebP, AVIF): throws away image detail that's hard for the human eye to notice, in exchange for a much smaller file. This is where nearly all of your savings come from.
Lossless (PNG): keeps every pixel exactly as it was, just stored more efficiently. Safer, but the reduction is much smaller — and on a photograph it barely helps at all.

If a file needs to shrink a lot, lossy is almost always the answer. Lossless is for the cases where pixel-exact accuracy genuinely matters: a logo, a screenshot with text that has to stay crisp, anything that will be edited further.

What the slider actually buys you

Here's the part most guides skip. The relationship between the quality number and the file size is not a straight line — it's steep at the top and nearly flat at the bottom. What that means in practice: at first it's remarkably efficient, and you cut the file right down without it showing in the quality. Push too far and the image starts looking worse while you save almost nothing more.

We measured it rather than repeating the usual advice. The table below is a single 1600×1200 test image encoded as JPG across the range, with the source image generated in code so the run is reproducible:

Quality	File size	Change vs quality 100
100	1220 KB	—
95	402 KB	−67%
90	234 KB	−81%
85	151 KB	−88%
80	118 KB	−90%
75	89 KB	−93%
70	75 KB	−94%
50	50 KB	−96%
30	34 KB	−97%

Read the first two rows again. Moving from 100 to 95 removes two thirds of the file. That single step costs almost nothing visually — at quality 100 a JPG encoder is spending enormous numbers of bytes preserving detail that is, by construction, below the threshold anyone will notice.

Then look at the bottom half. Between 70 and 50 you save another 25 KB — about 2% of the original. You are now trading visible quality for almost nothing. That's the real argument against cranking the slider down: not that low quality looks bad, but that below a certain point it stops buying you meaningful size.

So the practical rule:

Quality 100 is almost always a mistake. It's the single most expensive setting and the one nobody can distinguish from 95.
75–85 is where most photos should live. Essentially invisible at normal viewing size, and already past 88% of the possible savings.
Below 60, check before you commit. You'll start seeing blocking in skies and gradients — smooth areas are where lossy compression fails first and most visibly.

One caveat on that table: our test image carries a lot of fine grain, which is the hardest thing to compress, so the absolute numbers run higher than a typical smartphone photo. The shape is what transfers — steep at the top, flat at the bottom — and you can confirm it on your own files in about two minutes.

Compressing is the second step, not the first

If there's one thing worth taking from this article, it's this: resizing usually beats compressing, and people almost never do it.

A photo straight off a modern phone is somewhere around 4000 pixels wide. If it's going into a blog post that displays it at 800 pixels, you are storing 25 times more pixels than anyone will ever see. No quality setting can compete with simply not sending them.

Worth knowing about our own tool here: img-compress re-encodes but deliberately does not resize. A 4000×3000 photo comes back 4000×3000, just lighter. That's on purpose — how small an image should be depends entirely on where it's going, and silently deciding that for you would be the wrong default. But it does mean that if dimensions are your problem, scaling the image down first, then compressing, is the order that works.

Match the format to the content

Format choice moves the needle as much as the slider does, and in the wrong direction if you get it backwards.

Photographs → JPG for maximum compatibility, WebP or AVIF for a meaningfully smaller file at the same visual quality.
Screenshots, logos, line art, anything with text → PNG or WebP lossless. Lossy compression smears the hard edges of letters; a text screenshot saved as JPG typically comes out both blurry and larger than the PNG would have been.
Anything with a transparent background → PNG, WebP or AVIF. Save it as JPG and the transparency gets filled with white, permanently.

That last one is the most common unpleasant surprise when converting, and it's not reversible. WebP vs JPG vs PNG vs AVIF covers the full comparison.

Never re-compress a re-compressed file

Every lossy encode throws detail away permanently. Doing it to a file that has already been through the process throws away detail from an image that no longer has much to spare — this is called generation loss, and it compounds silently.

The practical version: if a file barely shrinks when you compress it, that's usually because it has been compressed before. That's a signal to leave it alone, not to drag the quality down until something gives. Go back to the original export whenever one exists, rather than re-saving a copy that has already made the round trip.

Batch settings work better than you'd expect

Images that came from the same source usually compress well at one shared setting. A set of photos from the same camera in the same lighting, or a folder of screenshots from the same application, will behave almost identically — there's rarely any value in tuning each file individually.

The exception is a mixed folder. Photos and screenshots want opposite things, so running both through at quality 80 will leave the photos slightly larger than necessary and the screenshots visibly damaged. Split those into two passes.

When you need to hit a specific size limit

Plenty of the time the goal isn't "smaller", it's "under 5 MB, because the form says so". Email attachments, job application portals and government uploads all impose hard ceilings, and the useful approach is different from general compression.

Work in this order, because each step is cheaper than the next in terms of what you give up:

Check the dimensions first. If it's a 4000-pixel phone photo and the limit is tight, scaling down is nearly free in perceived quality and will often get you under the line by itself.
Switch format before dropping quality. Converting a JPG to WebP at the same visual quality typically takes 25–35% off. That's a bigger, cheaper win than pushing the slider from 80 down to 60 — with the obvious caveat that the receiving end has to accept WebP, and upload forms frequently don't.
Only then lower the quality, and stop the moment you're under the limit rather than continuing for its own sake.

If the ceiling is brutal — some portals still cap at 1 or 2 MB — a photo that has already been through compression once may simply refuse to cooperate, for the generation-loss reason above. Starting again from the original export, if you have one, will get you further than squeezing the copy harder.

How to find your own number in two minutes

Any recommendation, including the one above, is an average over images that aren't yours. Checking takes almost no time:

Take one representative image — not the easiest one you have, a typical one.
Export it at 90, at 80, and at 70.
Look at all three at the size they'll actually be displayed, not zoomed to 400%. Zooming is how you talk yourself into files twice as large as you need.
Note the sizes. Pick the lowest setting where you can't tell the difference, then use it for that whole class of images.

The number you land on will usually be lower than you expected, and it will be right for your content rather than for a benchmark.

Where you compress matters too

A lot of "free image compressor" tools work by uploading your file to a server, processing it there, and sending it back. That's a copy of your image sitting on hardware you don't control, however briefly, with retention terms you probably haven't read.

img-compress skips that step: quality adjustment and format conversion both happen on your own device, so a batch of product photos, a passport scan, or anything more personal never leaves it. And you can check that rather than take our word for it: open your browser's developer tools, go to the Network tab, and compress a photo here. You won't see your image leaving as an upload.

How to Compress Images Without Losing Quality