How to Compress an Image Without Ruining It

A form says the file is too large. An email bounces. A page loads slowly on a phone. The usual advice — "just compress it" — skips the part that actually decides whether the result looks fine or looks chewed: there are two different ways to make an image smaller, and most people reach for the wrong one.

If you want the short version: open the image compressor, drop your files in, and if the image is larger than about 2,000 pixels on its longest side, cap the dimensions before you touch the quality slider. That one habit solves most oversized-image problems with no visible loss at all. The reasoning, and the cases where it doesn't apply, are below.

Two levers, and they're not interchangeable

A photo's file size comes from two things: how many pixels there are, and how many bytes each pixel costs. You can pull on either.

Resizing reduces the pixel count. A 4,000-pixel-wide phone photo cut to 2,000 pixels wide has a quarter of the pixels — halving each dimension quarters the area — and the file shrinks roughly in proportion. Crucially, the pixels that remain are still described at full fidelity. Nothing looks compressed; the image is simply smaller.

Re-compressing keeps every pixel but spends fewer bytes describing them. The encoder approximates more aggressively: fine texture gets smoothed, edges pick up faint halos, flat areas band. Push it far enough and you get the familiar mush.

Here's why the distinction matters so much in practice. A modern phone camera produces images around 4,000 pixels wide. Almost nothing you do with that photo needs 4,000 pixels. An email attachment, a web page, a support ticket, a form upload, a message — these are all viewed at a fraction of that size, and the extra pixels are thrown away by the viewer anyway. So resizing to a sensible maximum is nearly free: you discard data that was never going to be seen, and the picture looks identical where it's actually displayed.

Re-compressing, by contrast, degrades what you are looking at. It's a real tool, but it should usually be the second thing you try, not the first.

What maximum dimension should you pick?

It depends entirely on where the image is going, and generous is fine — you're still cutting the file dramatically.

The compressor offers 1,920 px and 2,560 px as one-click caps, plus a custom value, and it always scales the longest side while keeping the proportions — so nothing stretches and portraits stay portrait.

Why your PNG barely shrinks

This is the single most common frustration, and it isn't a tool failure — it's the format.

PNG is lossless. It reproduces every pixel exactly, which is precisely why it's the right choice for logos, screenshots and diagrams, where a lossy format would blur the text. But lossless means there's no quality dial to turn down. A PNG compressor can only look for smarter ways to pack the same exact pixels, and if the file was already saved by a competent encoder, there isn't much left to find. Re-encoding an already-optimised PNG in a browser can genuinely produce a file the same size or slightly larger.

So for a stubborn PNG you have three real options, in increasing order of effect:

• Resize it. This works on PNG exactly as well as on JPG, because fewer pixels means fewer pixels to store losslessly. Often enough on its own.
• Convert it to WebP. WebP does lossless and lossy, and is usually substantially smaller than PNG either way while still supporting transparency. For a screenshot or graphic destined for the web, this is normally the biggest win available. The Image Converter handles it, and what changes when you convert formats covers what to watch for.
• Convert it to JPG — but only if it's a photograph that was wrongly saved as PNG, and only if it has no transparency to lose. For graphics and text, JPG is the wrong answer; it will blur exactly the edges PNG was protecting.

A tool that claims to shrink any PNG by 80% with no loss is either resizing it without telling you, converting it, or quietly discarding colour depth. The compressor here takes the less impressive route: if re-encoding would produce a larger file, it keeps your original untouched and labels it already optimized, so you never download something worse than what you started with.

How much quality loss is actually visible

Compression levels are usually named rather than numbered, which hides what's happening. In this tool they map to concrete encoder quality settings — Light is cautious, Balanced is the sensible default, Strong is aggressive — and the honest summary is:

What matters as much as the level is what's in the picture. Lossy compression was designed for photographs, and it handles them well. It handles the following badly, at any level:

• Screenshots and anything with small text — letters get fuzzy halos and become hard to read.
• Logos, icons and line art — sharp edges smear.
• Large flat areas of colour — smooth gradients break into visible bands.
• Images with transparency — JPG can't store it at all.

For those, resize or switch format rather than turning the quality down. And if the image contains something sensitive that you're hoping compression will obscure — a name, an account number, a face — compression does not hide anything. It makes the picture slightly worse while leaving everything perfectly readable. That's a redaction job: see how to redact an image properly, or use the image redactor.

Hitting a specific limit

Most people compressing an image have a number to beat. The three common ones:

Email attachments

A personal Gmail account caps attachments at 25 MB, with larger allowances on some business plans; over that, Gmail offers a Drive link instead of an attachment. Other providers sit in the same region. Since a resized phone photo typically lands in the low hundreds of kilobytes, the practical trap isn't a single image — it's attaching fifteen full-resolution ones. Resizing a batch to 1,920 px usually takes a bounced email down to a few megabytes.

Upload forms

Forms often enforce much tighter limits than email — 2 MB and 5 MB are common, and the error message is frequently unhelpful about which one it is. Work in this order: resize to 1,920 px, check the size, then apply Balanced, then Strong if you still need to. Also check the format is accepted at all; a surprising number of "file too large" complaints are actually a rejected HEIC or WebP, which is a conversion problem, not a size problem.

Web pages

Here the number that matters isn't a cap but a loading target. Google's Largest Contentful Paint guidance treats 2.5 seconds or less as good, measured at the 75th percentile of real page loads — and on most pages the largest contentful element is an image, which makes image weight the thing standing between you and that threshold. The scale of the problem is well documented: the HTTP Archive's 2025 Web Almanac found the median mobile home page shipping roughly 911 KB of images against a median total transfer of about 2.56 MB.

For web work the biggest single win is usually not the quality slider at all. It's serving an image at the dimensions it's displayed at, in WebP, instead of a full-resolution JPG scaled down by the browser.

Compressing a batch

Compression is rarely a one-file job — it's a holiday album, a set of listing photos, a folder of receipts. Add them all at once and the same level and resize cap apply to every image, with the before-and-after size shown per file so you can see what each one actually saved rather than trusting a percentage claim. One file downloads on its own; several come back in a ZIP.

Two things worth knowing about batches. Output format follows input: a PNG stays a PNG, a WebP stays a WebP, and HEIC files from an iPhone come out as JPG, since HEIC is the one input that has no matching output. And the work happens on your own machine, so a large batch is limited by your device's memory rather than a server quota or a daily free-tier cap — if a very large set makes the tab sluggish, split it in two.

The part you can't undo

Lossy compression is one-way. The detail an encoder discards is not stored anywhere, so there is no setting, tool or service that recovers it. "Enhance" features guess at plausible detail; they don't restore the original.

Two consequences worth taking seriously:

• Keep your originals. Compress a copy for sending and leave the master alone, especially for anything you might print or edit later.
• Don't compress the same file repeatedly. Each pass compounds the damage of the last. If a file isn't small enough, go back to the original and compress harder in one pass rather than compressing the compressed version again.

Why doing it locally is worth caring about

Almost every free compressor works by uploading your images to a server, shrinking them there, and sending them back. It's a reasonable engineering shortcut and a strange privacy trade, because of what people compress to get under a size limit: the photo of a passport for a visa form, a scan of a payslip for a landlord, an insurance claim photo, medical paperwork, a signed contract. Those files go to an unknown company — complete with the GPS coordinates in their metadata — for an operation your own laptop can do instantly.

The RedactLocal compressor runs in the page. Images are decoded, resized, re-encoded and handed back as a download without leaving the tab. You can verify it rather than take it on trust: load the page, disconnect from the network, and compress anyway. It still works, because nothing was ever sent.

PDFs are a related but separate job with different mechanics — see reducing PDF file size and the PDF compressor.

Frequently asked questions

Does compressing an image reduce its quality?

Re-compressing does, by a controllable amount — Light is close to invisible, Strong is noticeable on close inspection. Resizing doesn't reduce quality in the same way: it reduces the pixel count, and the remaining pixels stay at full fidelity, so a resized image looks identical at the size it's actually displayed.

Why didn't my PNG get smaller?

PNG is lossless, so there's no quality to trade away, and an already-optimised PNG has little left to squeeze in a browser. Resize it, or convert it to WebP, which is usually far smaller and keeps transparency.

Should I resize or compress?

Resize first. Most images are far larger than they need to be for where they're going, so cutting the dimensions is nearly free. Re-compress only if resizing didn't get you under your limit.

Can I compress an image to an exact size, like 200 KB?

Not directly with presets — the output size depends on the picture's content, so no preset can promise an exact number. The reliable method is to resize to a sensible cap, apply Balanced, check the reported size, and step up to Strong or a smaller cap if you're still over. The per-file before-and-after sizes make that loop quick.

Can I undo compression or restore the original quality?

No. Lossy compression permanently discards detail. Always keep the original file and compress a copy.

What size should images on a website be?

Serve them close to the dimensions they're displayed at — commonly 1,600–2,000 px on the longest side for a full-width image — and prefer WebP. That matters more for loading speed than aggressive quality reduction does.

Does compressing a photo remove its location data?

Re-encoding in the browser writes a new file from the decoded pixels, so the original metadata block isn't carried over — but don't rely on that as a privacy step, since your original still has it and other tools behave differently. Remove metadata deliberately if that's the goal.

Will an image ever come out larger than it started?

Not from this tool. If compressing would produce a bigger file, your original is kept and marked already optimized, so the download is never worse than the input.

Does it work on a phone?

Yes. It runs in any current mobile or desktop browser, with no app to install. Very large batches are easier on a laptop simply because there's more memory to work with.