Short answer: resize the pixel dimensions first, then compress. Shrinking a 4000-pixel photo down to the size it is actually displayed at removes far more weight than dragging the quality slider down, and it costs you almost nothing in visible quality. Reach for quality only after the dimensions are right.
Sooner or later an upload form tells you the file is too big. A job application caps the photo at 200 KB, a CMS rejects anything over 500 KB, an email attachment bounces at 10 MB. The instinct is to drag the quality slider down until the number fits. That works, and it is usually the wrong move.
Here is the order that gets a better result in about the same amount of time.
First, look at the pixel dimensions, not the file size
A file size is a consequence. The two things that produce it are how many pixels the image contains and how many bits are spent describing each one. The first number is almost always where the waste is.
Open the image and check its dimensions. A photo straight off a modern phone or camera is typically 4000 to 6000 pixels wide. If it is going to be displayed at 600 pixels wide — a form field, a profile picture, an inline illustration — then roughly 97% of the pixels you are storing will never be seen. You paid for all of them, uploaded all of them, and the viewer's device downloaded and decoded all of them, in order to throw them away.
Halving both dimensions quarters the pixel count, and the file size falls roughly in proportion. Going from 4000 pixels wide to 1000 usually takes a 2 MB photo down to under 200 KB with the quality setting untouched — and it will look sharper on screen than the downsampled 2 MB version, because the browser no longer has to do that downsampling itself with a worse algorithm.
Use the image resizer for this step. Set the maximum width to whatever the image is actually displayed at, leave upscaling off, and keep the aspect ratio locked.
Then adjust quality, and stop when you cannot see it
Once the dimensions are sensible, quality has far less room to help — but it still has some. On a photograph saved as JPEG, the difference between 100% and 80% is usually invisible on any screen, and costs about half the file size. Between 80% and 60% most photos still hold up. Below about 50% you start to see it in two very specific places.
- Smooth gradients — skies, skin, studio backdrops — start to show banding, where a smooth transition becomes visible stripes.
- Sharp edges against flat colour — text, logos, wireframes — develop a halo of ringing artefacts around the edge.
That is because JPEG works by discarding high-frequency detail, and those are exactly the areas where the eye is most sensitive to it. It also explains why a screenshot full of text compresses badly as a JPEG no matter what you do: you are asking the format to throw away precisely the information that carries the content.
The rule that saves the most time
Photographs and screenshots need opposite treatment, and mixing them up is why compression so often disappoints.
| Kind of image | Best format | Typical result |
|---|---|---|
| Photographs, anything with smooth tonal variation | JPEG or WebP | 40–80% smaller at quality 75–80%, no visible change |
| Screenshots, diagrams, charts, UI | PNG, or WebP | Converting to WebP often saves 50–70% where JPEG would produce smearing and a larger file |
| Anything with transparency | PNG or WebP | JPEG cannot do it; it will fill the transparent area with black or white |
| Simple flat-colour graphics, icons | SVG | Often a few kilobytes regardless of display size, and sharp at any zoom |
If the image is a screenshot, try converting it to WebP before you touch the quality slider at all. It is very often the whole fix.
A worked example
A photo taken on a phone, being uploaded to a form that caps files at 200 KB:
- Starting point: 4032 × 3024 pixels, 3.1 MB. That is 12.2 megapixels, each costing about 2 bits per pixel — normal for a well-exposed photo.
- Resize to 1200 pixels wide: 1200 × 900, now 1.08 megapixels. At the same bits per pixel that predicts roughly 280 KB, and the actual result is around 290 KB.
- Quality 78 instead of 92: around 140 KB. Still comfortably over the 200 KB target, and indistinguishable from the original at the size it will be displayed.
Two steps, and the quality setting was the smaller lever of the two. The image is now 22 times smaller than it started, and on screen it looks the same or better.
Three things that are usually a waste of effort
Compressing an already-compressed file again
Every JPEG save is lossy. Re-encoding a JPEG at high quality does not restore anything; it stacks a second generation of artefacts on top of the first. Always work from the original. If all you have is a JPEG that has already been through several tools, a single careful pass is as much as it can take.
Chasing the absolute smallest file
There is no prize for the smallest possible file. The target is small enough, and the cost of going further is paid in visible quality. Stop when the picture looks right at the size it will actually be seen.
Trusting a percentage figure
Compression results depend enormously on the input. The same settings that shrink one photo by 80% will shrink another by 15%, because the second one was already efficiently stored. If a tool promises a fixed reduction percentage, it is either oversimplifying or quietly resizing your image as well.
A note on doing this without uploading
Image compression is one of the few tasks where running locally is not merely a privacy preference but a functional improvement: there is no upload, so there is no wait, and you can iterate — resize, look, adjust, look again — as fast as you can click. The image compressor does this in the browser tab, with a batch mode for when you have fifty files and the same target to hit. Nothing is transmitted, which matters when the files in question are scans of documents rather than holiday photos.
The short version: resize to the dimensions you actually need, then nudge quality down to around 75–80, and try WebP first if the image is a screenshot. That combination reaches almost any file-size limit, and it reaches it without the picture looking worse.