A single uncompressed photo can weigh more than the rest of your webpage combined. One 4 MB smartphone shot is enough to push a mobile page load past five seconds, and most visitors leave long before that. The fix is not buying more bandwidth — it is compressing your images the right way. Done properly, you can shrink photos by 60–80% with no difference anyone can see, and the whole process is free.
Step 1: Pick the right format before you touch compression
Format choice does more work than any slider ever will. A photo saved as PNG can be eight times larger than the same photo in a modern format, and no amount of quality tweaking closes that gap. Use this order of preference in 2026:
- AVIF — smallest files for photos, typically around 50% smaller than an equivalent-quality JPEG. Quality 60 is the common starting point. The trade-off is slow encoding: a few seconds per image instead of milliseconds, so it fits pre-built static assets, not on-the-fly pipelines.
- WebP — roughly 25–50% smaller than JPEG at matching visual quality, with near-universal browser support. Handles photos, graphics, transparency, and animation. This is the safe default for almost everything.
- JPEG — the legacy pick. Still fine when a client or an email client demands it (Outlook still does not render WebP), but never the default for web pages.
- PNG — only for logos, icons, screenshots, and graphics with sharp edges or transparency. Never for photographs.
If your browser matrix is modern, serve AVIF first with WebP as the fallback using the <picture> element. If you only want to maintain one format, make it WebP. The single biggest win available to most sites is simply converting old JPEGs to WebP, which alone cuts roughly a third to half the bytes.
Step 2: Resize first, compress second
Compression fights a losing battle against oversized dimensions. A 6000-pixel-wide camera photo destined for an 800-pixel-wide content column is carrying roughly fifty times the pixels it needs. Always downscale to the largest size you will actually display — plus a margin for high-density screens, typically no more than twice the displayed width.
The rule: resize first, then compress. Resizing after compression just wastes the encoder's effort, and compressing a giant image at a lower quality setting looks worse than compressing a correctly sized one at a higher setting. Export your masters at full resolution, but never ship the master to the web.
Step 3: Set quality like a pro — 80 is the magic number
Most quality sliders default to something unnecessarily high. The practical sweet spots, confirmed by years of independent testing:
- WebP: quality 80. Files 25–50% smaller than JPEG with no visible difference on photos.
- AVIF: quality 60 (or CRF 24–30 in AV1 terms). Comparable visual quality to WebP at quality 80, at noticeably smaller sizes.
- JPEG: quality 80–85. Dropping from 95 to 85 typically saves 30–40% with quality loss invisible at normal viewing distance.
- PNG: use lossless only. For graphics, run a palette-quantizing optimizer instead of re-saving — fewer colors, same pixels.
Never recompress a JPEG into another JPEG. Each lossy pass throws away more detail, and two generations of JPEG compression look visibly worse than one. Keep one master copy (original or PNG) and generate your web versions from that master every time. Also strip EXIF metadata from web copies — camera metadata adds tens of kilobytes and leaks location data.
Step 4: Compress with free tools
You do not need paid software. Two free tools cover nearly every situation:
Squoosh (Google's Chrome team). The best free option for single images. It runs entirely in your browser, so your files never leave your device, and it supports JPEG (via the excellent MozJPEG encoder), WebP, AVIF, and PNG with fine-grained controls — chroma subsampling, progressive encoding, palette reduction. The split-screen preview lets you compare quality settings at full zoom before you commit. Downsides: one image at a time, and AVIF encoding takes 10–30 seconds per photo.
TinyPNG (and TinyJPG). Smart lossy compression with a dead-simple drag-and-drop interface. The free web tier handles up to 20 images per batch with 5 MB per file, which covers most blog and portfolio workflows. TinyPNG's palette quantization is particularly strong for PNG screenshots and icons with limited colors. The catch is that your files upload to their servers — avoid it for sensitive client work.
For Mac users, ImageOptim is the classic free desktop option: drag a folder in, and it runs multiple compression engines (OptiPNG, MozJPEG, Zopfli) and keeps the smallest result. It is Mac-only but genuinely the fastest batch workflow on that platform.
For WordPress sites, plugins automate all of this at upload time. ShortPixel (100 images per month free) and Imagify (from the WP Rocket team) compress on upload, generate WebP/AVIF versions, and bulk-optimize your existing media library. Smush handles unlimited images on its free tier at slightly lower compression ratios.
Step 5: Automate the batch pipeline
One-off tools break down when you have hundreds of images. For developers, the Sharp library for Node.js is the standard: one function call generates WebP and AVIF versions of every source image, and it slots into any build script. The command-line equivalents are cwebp and avifenc from the libwebp and libavif projects:
cwebp -q 80 input.jpg -o output.webp— lossy WebP at the sweet-spot quality.cwebp -lossless input.png -o output.webp— pixel-perfect WebP for graphics.avifenc --speed 6 -q 60 input.jpg output.avif— balanced AVIF speed and compression.- A simple loop converts a whole directory:
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done.
Two cautions. First, AVIF encoding is 50–500× slower than WebP, so run it once during your build or upload pipeline, never per request. Second, animated content should go to animated WebP or short MP4 video — animated GIFs are typically 5–10× larger than the same animation in a modern format.
Step 6: Serve the right image to every visitor
Compression is only half the job; delivery is the other half. A single 1600-pixel image served to a 360-pixel phone wastes most of its bytes. Use responsive images: the srcset attribute lets the browser pick the size that fits the screen, and the <picture> element layers AVIF over WebP over a JPEG fallback so every browser gets the best format it understands.
Then turn on lazy loading. Native loading="lazy" on below-the-fold images costs one attribute and defers every off-screen download until the user scrolls. Combined with modern formats, a page that used to ship 8 MB of images can comfortably ship under 1.5 MB — the difference between a bounce and a conversion.