How to Compress Images Without Losing Quality
Short answer
Pick the format to match the content — JPG for photographs, PNG for screenshots and transparency, WebP for the web. Then resize the image to the dimensions it will actually be displayed at, which usually saves more than compression does, and export at 75–85% quality. Below 70% the artefacts become visible.
On this page
There are three levers on image file size — format, dimensions and quality setting — and people almost always reach for the third one first. That is backwards. Choosing the wrong format can cost you a factor of five, and shipping a 4000-pixel image into a 600-pixel slot wastes more data than any quality setting will ever recover.
Get the order right and you can usually cut a file by 80–90% with nothing visible lost.
Choose the format before anything else
Format is the decision that matters most, and it depends entirely on what is in the image.
| Content | Format | Why |
|---|---|---|
| Photographs | JPG | Lossy compression designed for continuous tone |
| Screenshots, UI, text | PNG | Lossless, keeps sharp edges crisp |
| Anything needing transparency | PNG or WebP | JPG has no alpha channel |
| Logos, icons, diagrams | SVG | Vector, scales with no size cost |
| Images for a website | WebP | Smaller than JPG at the same quality |
| Animation | WebP or MP4 | Both beat GIF substantially |
The two mistakes that cost the most:
Saving photographs as PNG. PNG stores every pixel exactly. For a photograph, where no two adjacent pixels are identical, there is nothing to compress losslessly — so you get a file three to eight times larger than the JPG would be, with no visible benefit.
Saving screenshots as JPG. JPG’s compression assumes smooth gradients. Apply it to black text on white and you get grey haloes and fringing around every letter. The file may be smaller, but it looks worse and cannot be fixed.
A note on GIF
GIF is limited to 256 colours and compresses poorly. For a static image, use PNG or JPG. For animation, a WebP or a short MP4 is typically a fraction of the GIF’s size at better quality. There is no situation left where GIF is the right technical choice.
Resize before you compress
This is the single largest win available and the most frequently skipped step.
File size scales with the pixel count, which scales with the square of the dimensions. Halving both width and height removes roughly three quarters of the data. A 4000×3000 photo cut to 1200×900 has about 9% of the original pixels — a far bigger reduction than any quality slider produces.
Sensible target widths:
| Use | Width |
|---|---|
| Full-width web banner | 1600–2000px |
| In-article image | 1000–1400px |
| Thumbnail | 300–500px |
| Email attachment | 1200–1600px |
| Printing at A4 | 2480px (300 DPI) |
The rule is simple: never ship an image substantially wider than the space it will be displayed in. The only exception is high-density displays, where roughly 2× the layout width is worth serving.
Resizing is available everywhere without extra software — Preview on macOS (Tools → Adjust Size), Photos or Paint on Windows, and the Photos app on both iPhone and Android when you crop.
Then set the quality
With the format and dimensions right, the quality setting is the fine adjustment.
For JPG and WebP, 75–85% is the working range. Within it, the compression is discarding detail your eye does not resolve at normal viewing distance. Below about 70%, artefacts become visible where you would least like them: banding in skies, blockiness in shadows, mush around fine detail.
Two rules to keep:
- Never re-save a JPG. Each save re-encodes and compounds the previous losses. Keep the original — camera file, PNG, or PSD — and export a new JPG whenever you need one.
- Compress once, at the end. After cropping, colour adjustments and resizing, not before.
Our image compressor runs entirely in the browser, so files are never uploaded anywhere, and it shows the before-and-after size as you move the quality slider. That comparison is the fastest way to develop an instinct for where the threshold sits on your own images.
When lossless actually matters
Most of the time it does not, and insisting on lossless costs you size for no benefit. But there are cases where it genuinely matters:
- Screenshots containing text. Documentation, UI references, error messages. Lossy compression damages exactly the part people need to read.
- Images you will edit again. Every intermediate save should be lossless; compress only the final export.
- Line art, diagrams and charts. Hard edges and flat colour are where JPG looks worst and PNG compresses best.
- Medical, scientific or legal imagery. Artefacts can be mistaken for content, and altered pixels can matter evidentially.
- Archival originals. Keep one untouched copy. Storage is cheap; the original is not recoverable.
For these, PNG is the safe default. Note that PNG has a legitimate lossless optimisation of its own — reducing the colour palette and stripping metadata — which can cut a screenshot by 20–50% without altering a single visible pixel.
Batch work and metadata
If you have a folder of images rather than one, two things are worth knowing.
Metadata adds up. Camera files carry EXIF data — exposure settings, camera model, lens, and often GPS coordinates. It is only tens of kilobytes per file, but across hundreds of images it matters, and the location data is a privacy issue if you are publishing them. Most export dialogs offer to strip it.
Consistency beats per-file tuning. Pick one target width and one quality setting for the whole set rather than optimising each image individually. The difference in total size is small and the time saved is not.
Preview on macOS handles batches natively: select all the files, open them in one window, then Tools → Adjust Size applies to the whole selection.
Where this connects to other problems
Oversized images are the hidden cause of several things that look unrelated.
Large embedded images are the main reason PDFs become too big to email — see how to reduce PDF file size, where downsampling images to 150 DPI does most of the work.
They also cost memory in the browser. A decoded bitmap in memory is far larger than the compressed file on disk, so a page full of full-resolution photos is a real contributor to Chrome using too much RAM.
And on phones, photos are almost always the largest storage category, which is why freeing up iPhone storage starts with the Photos app rather than with apps.
What does not work
- Zipping images. JPG, PNG and WebP are already compressed. A zip saves almost nothing and makes the files harder to use.
- Converting PNG to JPG for a screenshot. Smaller, visibly worse. Optimise the PNG instead.
- Compressing an already-compressed JPG again. Generation loss with barely any size gain.
- Upscaling a small image. It adds pixels and file size without adding detail. AI upscaling is better than it used to be, but it invents detail rather than recovering it.
Realistic expectations
A typical smartphone photo — around 4000 pixels wide and 3–6MB — resized to 1400 pixels and exported as JPG at 80% lands somewhere in the low hundreds of kilobytes. That is a reduction of roughly 90%, and at the size it will be displayed, nobody can tell the difference.
If you can see the difference, you compressed too hard or resized too far. Go back to the original and try again — which is exactly why keeping that original matters.