How to Reduce Image File Size Without Losing Quality
Last updated: October 2026. Big image files are the most common reason a page loads slowly, an email bounces back, or a phone runs out of storage. The good news is that most images carry far more data than anyone can see. This guide explains where the waste comes from, how lossy and lossless compression differ, which format suits each job, and what the quality slider in a compressor is actually doing — so you can shrink a file deliberately instead of guessing.
Why image file size matters
Images are usually the heaviest part of any web page. A single unoptimised photo can weigh more than all of a page's HTML, CSS and JavaScript combined, and on a slow mobile connection that translates directly into a blank screen and a visitor who leaves. Search engines measure the same thing through page-experience signals, where large images hurt the Largest Contentful Paint metric — the moment the main picture finally appears.
The same file causes smaller but equally real problems elsewhere. Email providers cap attachments (Gmail around 25 MB, Outlook around 20 MB), so a handful of phone photos can exceed the limit before you have written a sentence. Cloud storage and phone backups fill up with duplicates of pictures that were already larger than needed. And every megabyte you shave is a megabyte not uploaded, not downloaded and not paid for on a metered mobile plan. The goal is never "the smallest possible file" — it is the smallest file that still looks right at the size it will actually be viewed.
Lossy vs lossless compression, in plain English
Lossless compression is like zipping a document: the encoder finds redundancy and stores the same pixels more efficiently. Decode it and every value is identical to the original. PNG is lossless, and its optimisers (including the OxiPNG engine behind our PNG compressor) re-encode the same pixels in fewer bytes without touching a single colour. The catch is that lossless compression cannot beat the information actually present — a photographic PNG stays large because photographs are full of subtle, non-repeating detail.
Lossy compression deliberately throws away detail that the human eye is unlikely to notice: slight colour shifts, fine texture in busy areas, precision in the darkest shadows. JPG is always lossy. WebP, AVIF and JPEG XL offer both modes, and in lossy mode the encoder is not storing "80% of the pixels" — it is spending a budget on the parts of the image your eye cares about most. That is why a well-encoded lossy photo at a sensible setting can look indistinguishable from the original at a third of the size, while a badly over-compressed one shows blocky patches, smeared edges and colour banding in smooth gradients.
One rule matters more than any setting: compress from the original, once. Every lossy re-save adds a fresh generation of damage, and repeated round trips degrade a photo far faster than a single slightly stronger pass. Keep the master file and treat compressed copies as disposable exports.
Choosing the right format
Format choice usually matters more than nudging the quality slider. The table below is directional — exact savings depend on the image — but the ranking holds for typical photographs and screenshots.
| Format | Best for | Transparency | Typical size vs JPG | Watch out for |
|---|---|---|---|---|
| JPG | Photos, camera output, anything that must open everywhere | No | baseline | Always lossy; artefacts grow with every re-save |
| PNG | Screenshots, logos, sharp UI graphics, transparent images | Yes | Often much larger for photos | Lossless, so it cannot shrink photographic detail much |
| WebP | General web images, photos and graphics alike | Yes | ~25–35% smaller | Some older desktop apps still refuse it |
| AVIF | Photo-heavy pages where bandwidth is the priority | Yes | ~40–50% smaller | Slow to encode; editing support still uneven |
| JPEG XL | Archives, lossless masters, future-proof libraries | Yes | ~30–50% smaller, plus lossless JPG recompression | Decoding is now broad, but many apps still cannot open it |
Two support facts are worth stating precisely, because a lot of advice online is out of date — and the two formats are not in the same place. AVIF has broad support in every current browser, so publishing it for display is safe; still, no browser can encode it natively — every AVIF you make is produced by a separate encoder, which is why the tools here use WebAssembly. JPEG XL is further behind: Chrome decodes .jxl by default since version 155 (October 2026), Firefox since version 158 (October 2026), Safari has shown still images since version 17, and Edge is still catching up. No browser encodes JPEG XL natively either. The practical takeaway: AVIF is safe to publish as-is, while JPEG XL should be served through a <picture> element with a JPG or WebP fallback — and for sharing with people and apps you do not control, keep a JPG or PNG path out for both.
What the quality slider actually does
Quality settings are the most misunderstood control in any compressor. The number is not a percentage of the original data and it is not comparable across formats — every encoder defines its own scale. On this site the sliders run from 30% to 100%, where higher means "preserve more detail, produce a bigger file." A few practical reference points:
- 70–85% is the sweet spot for photographs on the web. At these settings most images are visually indistinguishable from the source at normal viewing size, while file size drops sharply compared with 95–100%.
- 90%+ is for printing, pixel-peeping and images that will be edited again later. Size climbs quickly for gains few people can see on a screen.
- Below 60% is a deliberate trade: fine texture disappears, edges get blocky and smooth skies or skin tones start to band. It can still be right for thumbnails and previews, but test on the actual image.
- 100% on a lossy format still is not lossless. Only a genuinely lossless mode — PNG, or the lossless setting in WebP, AVIF and JPEG XL — returns the exact original pixels. For a PNG, "quality" typically controls optimisation effort rather than visual fidelity.
Diminishing returns are steep. Going from 85% to 95% often adds a third to the file size for a difference visible only when zoomed in; going from 95% to 100% can nearly double it again. Compressing a photo at 80% and viewing it at the size it will be displayed is almost always smarter than storing it at 100% and trusting that extra bits are buying quality.
And before you touch quality at all, check the dimensions. Resizing is usually the biggest single win. Halving both width and height cuts the pixel count to a quarter, so a 4000-pixel-wide camera photo rendered in an 800-pixel-wide article column is wasting 96% of its pixels. Use Resize Image to set a sensible longest edge first, then compress — the result is smaller and encoding is faster too.
Common scenarios, with settings that work
The right answer depends on where the image is going. These starting points cover most everyday jobs; adjust after looking at the result.
| Scenario | Format | Quality | Also do this |
|---|---|---|---|
| Website or blog images | WebP, or AVIF for the smallest files | 75–80% | Resize to the rendered width — rarely more than 1600 px |
| Email attachments | JPG | 70% | Resize the long edge to 1600–2000 px; keep the total under 10 MB |
| Social media | JPG or WebP | 80–85% | Upload around 2048 px on the long edge — platforms recompress anyway |
| Printing or archiving | PNG lossless, or JPG | 95%+ | Keep the original master; never overwrite it with a compressed copy |
| Screenshots and UI | PNG, or lossless WebP | lossless | Crop to the relevant area before optimising |
Websites and blogs. Serve WebP if you want a set-and-forget format every browser handles, or AVIF when bandwidth is the whole game and you can tolerate slower encoding. Quality 75–80% is plenty for photos; sharp text in screenshots prefers PNG. If you publish through a CMS, upload the compressed file rather than relying on the platform to do it well.
Email attachments. Nobody needs a 12 MB photo to see a birthday picture. JPG at around 70% with the long edge reduced to 1600–2000 pixels typically lands in the low hundreds of kilobytes and looks fine on a phone or laptop. If you are sending several images, compress each one rather than zipping a pile of originals.
Social media. Every major platform re-encodes what you upload, so pre-compressing at maximum quality buys nothing — the platform will throw detail away regardless. Upload a sensibly sized JPG or WebP at 80–85%, and avoid uploading a huge PNG screenshot when a JPG would do.
Printing and archiving. Here the priority flips: keep detail and keep a master. Store photos as PNG (lossless) or high-quality JPG at 95% or above, and never treat a compressed export as your only copy. For a smaller archival master, JPEG XL's lossless mode can repack an existing JPG without changing a pixel — see the JPEG XL guide for how that works and where browser support stands.
A simple workflow that avoids most mistakes
- Start from the original. Never re-compress an already compressed copy; each pass stacks artefacts.
- Resize before compressing. Decide the largest size the image will be displayed at and discard the rest with Resize Image.
- Pick the format by destination. Web or app you control: WebP or AVIF. Email, upload forms or unknown software: JPG. Transparency or sharp text: PNG.
- Set quality once, then compare. Start at 80% for photos, look at the result at 100% zoom, and only move the slider if you can actually see a difference.
- Keep the master. Archive the original; share and publish the export.
Tools on this site for the job
Everything below runs entirely inside your browser — the encoders are WebAssembly or the browser's own canvas, and your files are never uploaded. That matters for private photos and client work, and it also means there is no queue, no daily limit and no watermark. The privacy model is explained in our no-upload guide.
- Shrink in the same format: Compress JPG and Compress PNG — the quickest route when a file must stay JPG or PNG.
- Fix the dimensions first: Resize Image handles JPG, PNG and WebP sources and lets you choose the output format.
- Move to a smaller modern format: JPG to WebP, PNG to WebP, JPG to AVIF and PNG to AVIF.
- Go deeper on the formats: the AVIF guide and the AVIF vs WebP vs JPEG XL comparison explain the trade-offs behind the table above.
All 38 tools on the site work the same way: choose a file, adjust the setting, download the result. If a guide like this one is missing a case you care about — or a result looks wrong — tell us and we will look into it.