Every "my image is too big" problem is one of three problems. Knowing which one you're solving is the difference between a 200 KB output and an 8 KB output. They're not interchangeable, they're not all called "compression", and most online tools quietly do the wrong one because they assume you wanted compression.
The three operations
Compression keeps the image's pixel dimensions but reduces how many bytes describe each pixel. JPEG quality 95 → quality 75 is compression. PNG with no optimisation → PNG with palette reduction is compression.
Downsampling reduces the pixel dimensions themselves. A 4000×3000 photo to 1500×1125 is downsampling. The image now contains fewer pixels — there's nothing left to compress that doesn't exist.
Format conversion changes the encoding scheme entirely. PNG → WebP is conversion. JPEG → AVIF is conversion. Same pixels, different storage format, often different quality/size trade-off.
Each one solves a different problem. Use the wrong one and you get bigger files than you started with, or visible quality loss, or both.
When to compress
Compress when the image is at the right pixel dimensions for its destination, and you just want fewer bytes per pixel. The classic case: a hero photo on a website at 1920×1080, exported from Lightroom at JPEG quality 100, weighing 4 MB. The image is the right size; it just has more colour fidelity than the human eye can perceive at that resolution. Drop quality to 80 (the diminishing-returns elbow of JPEG), get a 600 KB file, no visible difference.
Don't compress an already-compressed JPEG and expect more savings. Each JPEG re-encode loses a small amount of quality (and adds artefacts) without proportional file size gain. Compressing a 600 KB JPEG to 580 KB while introducing visible blocking is the worst trade in the catalogue.
When to downsample
Downsample when the image is bigger than the largest place it will be displayed. The most common version of this: a photo from your phone is 12 megapixels (~4000×3000). You're using it as a thumbnail in a blog post, where it'll display at maybe 600×450. The other 95% of the pixels are paying rent on your CDN bill.
Rule of thumb: downsample to 2× the maximum display size for retina screens, 1× for everything else. A blog post that displays images at 800 px wide should serve images at 1600 px wide and not 4000. The eye can't tell the difference; the loading time can.
Always downsample before compressing. Compressing a 4000×3000 image to JPEG quality 60 gives you a smaller file than the original, but a much bigger file than first downsampling to 1600×1200 and then compressing at quality 80. The order matters.
When to convert format
Convert format when the file's encoding is wrong for its content. The big traps:
- PNG of a photo. PNG is lossless and great for screenshots, diagrams, anything with sharp edges and limited colours. PNG of a 12-megapixel photograph is the worst possible choice — it can be 10× the size of a quality-90 JPEG of the same image with no visible quality benefit. Convert to JPEG or WebP.
- JPEG of a screenshot. JPEG's block compression smears sharp text and pixel-perfect UI edges. Screenshots should be PNG or WebP-lossless. A JPEG screenshot at quality 90 is both bigger AND uglier than a PNG of the same image.
- BMP, TIFF, or any uncompressed format on the web. These exist for archival and print workflows, not for the open web. Convert to PNG (graphics) or WebP/JPEG (photos).
- Animated GIF for anything modern. Animated WebP and AVIF are 10-20× smaller. The only reason to use GIF in 2026 is broken Slack/Discord previews and even those mostly work with WebP now.
WebP is the safe modern default for both photos and graphics — better compression than JPEG and PNG, supported by every browser since 2020. AVIF compresses photos even smaller (~30%) but encodes slowly and lacks support in old Safari. JPEG is the universal fallback. PNG is for graphics where you need transparency or absolute pixel preservation.
The decision tree
- Is the image bigger than the place it will be displayed? If yes — downsample first. Stop here for now.
- Is the image format wrong for its content? (PNG photo, JPEG screenshot, BMP anywhere) — convert format. WebP is a safe default for both kinds of content.
- Is the file still bigger than you want? Now compress. Quality 75-80 for JPEG and WebP-lossy. PNG only really compresses if it has a limited palette (<256 colours), in which case palette reduction is the move.
- Is the file STILL too big? You probably can't go further without visible quality loss. Re-evaluate whether you need that resolution or that format at all.
One more — the EXIF question
Photos from phones carry EXIF metadata: camera model, lens, exposure, often GPS coordinates. The metadata is small (a few KB), so it's not a meaningful size win to strip it, but it's a meaningful privacy win — uploading a photo straight from your phone to a public profile means broadcasting where you took it.
Most online compressors and resizers strip EXIF as a side effect, which is good for privacy but bad if you're a photographer trying to preserve the technical metadata for a portfolio. Check the tool you're using.
Most image-too-big problems take less than thirty seconds when you've identified which of the three operations applies. Most of the wasted time on this problem is people running the wrong operation and being disappointed by the result.