How to reduce image file size without ruining quality

Most oversized images aren't one mistake — they're three or four stacked on top of each other: too many pixels, the wrong format, a timid quality setting and a pile of metadata. Fix them in the right order and a 4 MB photo routinely becomes 150 KB with no visible difference.

Step 1: resize the dimensions — the biggest win by far

File size scales with pixel count, and pixel count scales with the square of the dimensions. A modern phone photo is around 4000×3000 pixels — 12 million pixels. If it will be displayed in a 800-pixel-wide blog column, you're shipping roughly 14× more pixels than anyone can see. Halving both dimensions alone cuts the file to about a quarter of its size, before any compression tricks.

Practical width targets:

Full-width hero images: 1600–2000 px wide covers virtually all screens (use 2× only if you serve responsive variants).
In-content images and blog photos: 800–1200 px wide.
Thumbnails and avatars: 160–400 px.
Email attachments: 1200–1600 px on the long edge prints fine at snapshot sizes and keeps attachments small.

The image resizer does this in your browser — set a width, keep the aspect ratio locked, and never scale up (upscaling adds bytes but no detail).

Step 2: pick the right format

The classic mistake is a photograph saved as PNG. PNG is lossless, so it faithfully stores millions of subtly different pixel values — exactly what photos are made of — and produces files 5–10× larger than a visually identical JPEG or WebP. The quick rules:

Photos: JPEG for maximum compatibility, WebP for ~25–35% smaller files on the web. Converting to WebP is usually the single easiest saving after resizing.
Screenshots, UI, diagrams: PNG or lossless WebP — lossy formats smear sharp text edges.
Logos and icons: SVG if you have it; otherwise PNG/lossless WebP at the display size.
Animation: MP4 video, not GIF — typically 5–10× smaller for the same clip.

For the full decision tree, see our guide to the best image format for the web.

Step 3: set quality to the sweet spot — then stop

Lossy encoders take a quality value from 0–100, and the size-vs-quality curve is steeply non-linear. The last few points of quality are wildly expensive: going from quality 85 to 100 can double or triple a JPEG's size while changing nothing you can see at normal viewing distance. The well-tested sweet spots:

JPEG: quality 75–85. Below ~70, blockiness and ringing around edges start to show; above 85 you're paying for invisible precision.
WebP: quality 70–80. WebP's scale runs slightly "lower" than JPEG's — WebP 75 looks roughly like JPEG 85.
AVIF: quality 50–65 often matches JPEG 80+ visually, at half the bytes.

Judge results at 100% zoom on the parts that fail first: skies and smooth gradients (banding), hair and foliage (smearing), and any text (halos). If those survive, the rest is fine. A live-preview image compressor makes this a 10-second visual check instead of guesswork.

Step 4: strip the metadata

Cameras and phones embed EXIF data — timestamps, camera model, GPS coordinates, sometimes a full-size preview thumbnail — plus colour profiles and editing-software fingerprints. That's typically tens of kilobytes, occasionally more. On a 2 MB photo it's noise; on a 60 KB web image it can be 20% of the file. Stripping metadata is also a privacy measure: GPS coordinates in a photo's EXIF reveal exactly where it was taken, and most social platforms strip it for that reason. Re-encoding an image through a converter or compressor produces a clean file without the original's metadata; keep one archived original if you want the capture data preserved somewhere.

Realistic size targets

"As small as possible" isn't a spec, so here are working numbers:

Hero/banner image: under 200 KB (under 100 KB with AVIF is very achievable).
In-article photo: 50–150 KB.
Thumbnail: 5–30 KB.
Whole page image budget: under ~1 MB total keeps Largest Contentful Paint healthy on mid-range mobiles.
Email: keep total attachments under ~10 MB; many corporate servers still bounce beyond that. Also note Gmail and Outlook clip messages over ~102 KB of HTML.
Upload forms: when a form says "max 2 MB", resize to the required pixel dimensions first — that alone usually gets you under the cap.

The order matters

Do it as listed: resize → format → quality → metadata. Compressing first and resizing after means re-encoding an already-lossy image (quality loss compounds), and each step's savings multiply with the others. A typical 4032×3024, 3.5 MB phone photo destined for a blog post: resize to 1200 px wide (~450 KB as JPEG 90), convert to WebP at quality 75 (~90 KB), metadata already gone in the re-encode. That's a 97% reduction with no visible change at display size.

Frequently asked questions

How do I reduce file size without losing quality at all?

Strictly losslessly, your options are: resize the dimensions (technically lossy in pixels, but lossless at display size), re-compress PNGs with a better optimiser, convert PNG to lossless WebP (~25% smaller), and strip metadata. Beyond that, well-tuned lossy compression at quality 75–85 is "visually lossless" — different bytes, identical appearance.

What's the best image size for a website?

Match the pixels to the largest size the image is actually displayed at (times two, at most, for high-DPI screens), then compress to WebP or AVIF. For most content images that means 800–1200 px wide and 50–150 KB.

Why is my PNG so huge?

It's almost certainly a photograph or screenshot containing photographic content. PNG stores such images losslessly and inefficiently. Convert photos to JPEG, WebP or AVIF; keep PNG for flat graphics, text-heavy UI and transparency.

Does compressing an image reduce its quality every time?

Every lossy re-encode loses a little, and the losses stack. Always compress from the best original you have, not from a previously compressed copy — and keep originals for anything you may need to re-export.

Related guides

WebP vs PNG — why the format choice alone can triple or shrink your file.
AVIF vs WebP — squeezing out the next 20–40% once you're already on WebP.