How to compress images for the web without losing quality

Toolkit Guides · Updated July 2026 · 7 min read

The title hides a small confession: every lossy save loses something. The honest version is “without losing quality anyone can see,” and that is a much easier promise to keep than most people expect — if you do things in the right order. The order is the whole trick: fix the dimensions first, then pick the format, then — last and least — touch the quality slider. Most oversized images on the web come from doing it backwards: uploading a camera-sized photo untouched, or crushing quality down to 40 to compensate for dimensions nobody checked.

Why images, specifically

Break a typical web page into its parts and the imbalance is stark. The HTML, stylesheets and scripts are measured in tens or hundreds of kilobytes; a single photo straight off a phone is measured in megabytes. Images routinely account for more of a page's weight than everything else combined, which makes them the first place to look when a site feels slow — and the place where an hour of work pays back the most.

The cost is not abstract. Heavy images crawl on cellular connections, burn through visitors' data plans, and drag the numbers search engines now measure: Google's Core Web Vitals track how quickly a page's largest visible element renders, and on most pages that element is an image. A 4 MB hero photo is a self-inflicted wound that every visitor pays for on every visit.

Step one: resize the dimensions

Here is the arithmetic that quality-slider fiddling ignores. A phone photo at 4000×3000 pixels contains 12 million pixels. A blog column displays it 800 pixels wide — call it 800×600, or 480,000 pixels. The original holds 25 times the pixels the page can show. Every one of them is downloaded and decoded before the browser scales the image down to fit and throws the rest away.

No quality setting rescues that file, because the waste is in the pixel count, not the encoding. Resizing to the display size removes the bulk of the weight at zero visible cost — it is the only genuinely free step in the whole process, which is why it goes first.

How big should the resized copy be? The largest size the image will actually be displayed at, doubled to stay sharp on high-density (“retina”) screens: an 800-pixel-wide slot gets a 1600-pixel-wide image. Beyond 2× buys nothing anyone can see. And never enlarge — upscaling cannot create detail that was not captured; it just makes a blurrier file bigger.

Do the resize: the image resizer exports exact pixel dimensions, and both the image compressor and the image converter accept an optional max width to shrink proportionally while they work.

Step two: put it in the right format

The classic heavyweight is a photograph stored as a PNG. PNG is lossless, which sounds like a virtue but is the wrong tool for photographic content: it cannot exploit the noisy, never-repeating texture of a real-world scene, so it produces files five to ten times larger than a JPG that looks identical. If a photo is sitting in a PNG, converting it to JPG or WebP is an enormous saving before any actual compression happens. One caveat: JPG has no transparency, so a photo with a cut-out background flattens onto white when converted — use WebP for those.

The reverse mistake matters too. Screenshots, charts and interface images belong in PNG; saving them as JPG smears the text with halos and rarely saves much. If a PNG screenshot is too big, shrink its dimensions rather than switching it to a lossy format.

As a rule: WebP for pages you control (it is typically smaller than JPG at the same visual quality, and every current browser reads it), JPG for files that get emailed or handed around. The full map of which format suits which content is in the image format guide.

Step three: the quality slider, last

The quality number is not a percentage of anything real — it is a knob for how aggressively the encoder discards detail. What matters is what each range actually looks like on a photo:

Quality	What you get
95–100	Looks identical to 85 but the file is often twice the size. For archiving and print handoffs, not the web.
85–95	Clean under close inspection. Product photography, portfolio images.
70–85	The web sweet spot — at normal viewing size, most photos are indistinguishable from the original.
55–70	Much smaller; smooth gradients like skies may start to band. Fine for thumbnails.
Below 50	Visible blockiness, halos around edges, plasticky texture. Only when size is everything.

Damage always shows up in the same places first: smooth gradients band into stripes, sharp boundaries grow faint halos, and fine texture — hair, foliage, fabric — turns smooth and artificial. Check those areas at 100% zoom at the size the image will actually display. Everything looks broken at 400% zoom; nobody views your site that way.

For web photos, 70–85 is the range to live in — the image compressor defaults to 75 for exactly this reason. At normal viewing distance, most people cannot pick the 75 out of a lineup with the original. Everyone can spot the 40.

The whole workflow, five minutes flat

Work on a copy. The original is your archive; compression is for the version you publish.
Resize to about twice the displayed width — 1600 px for an 800 px slot — with the image resizer or a max-width setting.
Fix the format if needed: photos out of PNG and into JPG or WebP with the image converter; screenshots stay PNG.
Compress at 75–80 in the image compressor and watch the live before/after size readout. Nudge the slider down until just before you can see a difference, then stop.
Sanity-check the result. A hero image under roughly 200 KB, inline photos under 100 KB, thumbnails a few tens of KB. Those are habits, not laws — but a 2 MB blog photo means a step got skipped.

All of these tools run entirely in your browser, so the photos never upload to any server — here is how that works. A useful side effect of re-encoding: the output file carries none of the original's hidden metadata, like GPS coordinates — usually exactly what you want for public images (more on that here).

The honest limits

Do not recompress the already-compressed. Running a 200 KB JPG through the process again to reach 180 KB buys almost nothing and costs real quality — lossy generations stack, and the smudging compounds with each save. When an image needs editing, go back to the original and re-export once.
Some images are legitimately big. A full-width panorama with fine detail everywhere carries real information; forcing it under an arbitrary budget makes it visibly bad. Budgets are guidance, not physics.
Lossy is one-way. There is no un-compress. If you kept no original, the 55-quality version is now the master — which is the strongest argument for step one of the workflow.
Be skeptical of “zero loss” claims. If a tool promises photos dramatically smaller with no quality loss at all, it is re-encoding lossily whether the marketing says so or not. Genuine lossless optimizers exist for PNG, but their savings are modest.

The bottom line

Dimensions first, because that is where most of the waste lives. Format second, because a photo in a PNG cannot be saved by any slider. Quality last, somewhere in the 70–85 band, judged at real size with your own eyes. Keep the original, publish the copy, and do not compress the same file twice. That is the entire discipline — five minutes in a browser tab, no software installed, and pages that stop making visitors wait.