Most of the web's image weight ships on autopilot: photos saved as JPEG because that's what the camera exported, graphics as PNG because that's what the designer sent. Choosing deliberately is worth real money — WebP cuts 25-34% off an equivalent JPEG, AVIF cuts about half. Here's the sorting, the settings, and the page-speed math.
The short version, by job:
Now the reasoning behind each call.
| Format | Compression | Transparency | Animation | Typical size for the same photo | Support |
|---|---|---|---|---|---|
| JPEG | Lossy | No | No | baseline | universal |
| PNG | Lossless | Yes | No | 3-5× larger than JPEG | universal |
| WebP | Lossy + lossless | Yes | Yes | 25-34% smaller than JPEG | all browsers since 2020 (96%+) |
| AVIF | Lossy + lossless | Yes | Yes | ~50% smaller than JPEG | mid-90s% and climbing |
| GIF | 256-color LZW | 1-bit only | Yes | many times larger than WebP | universal |
| SVG | Vector (text) | Yes | CSS/SMIL | not comparable — resolution-free | universal |
Google's compression studies — the ones that got the format adopted — measured lossy WebP at 25-34% smaller than JPEG at equivalent perceptual quality, and lossless WebP at 26% smaller than PNG. On a real page the numbers land where you'd expect: a 2.4 MB hero JPEG typically lands around 1.6-1.8 MB as quality-80 WebP, before any resizing.
Resizing is the quiet half of the story. A phone photo at 4032 × 3024 pixels displayed at 800 pixels wide ships sixteen times more pixels than the browser needs; converting the format without fixing the dimensions saves a third of the bytes while leaving two-thirds of the waste behind. The image compressor does both in one pass — format conversion, quality slider, and a max-width field — entirely in your browser, which also makes it the private option for images you'd rather not upload to anyone's server.
Close, with one operational catch. AVIF (the still-image profile of the AV1 video codec) typically lands around 50% smaller than JPEG, handles harsh gradients better than WebP at low quality, and finally cleared the support hurdle when Safari shipped it in 2023 — Chrome had it since 2020, Firefox since 2021. Global coverage now sits somewhere in the mid-90s percent.
The catch is encoding cost. AVIF is slow to produce — seconds instead of milliseconds per image — which matters on upload-heavy pipelines, and older tooling doesn't emit it. The standard play is a <picture> element with AVIF first, WebP second, JPEG last; browsers take the first thing they understand. If your pipeline can only produce one format today, make it WebP and revisit AVIF later.
Whenever the image has something to lose. PNG is lossless — decode it a thousand times and the pixels never drift — and it stores an 8-bit alpha channel, so soft shadows over any background survive. That combination is exactly what logos, interface icons, text screenshots, and charts need: hard edges that JPEG's blocky compression visibly smears, and transparency that JPEG can't represent at all.
For photographs PNG is almost always the wrong call, at 3-5× the JPEG weight for a difference nobody can see. And if you need lossless and smaller, lossless WebP typically beats PNG by about a quarter — the old format's remaining edge is pure compatibility.
Lossy compression, yes — that's the deal: the encoder throws away detail your eye is bad at noticing in exchange for bytes. The practical question is how far you can push it, and the answer is generous. At quality 80 and above, a WebP or JPEG of a photograph is effectively indistinguishable from the original at normal viewing sizes. Below 60 you start to see blocking and banding in smooth areas — skies, skin, gradients get ugly first.
Two habits matter more than the exact number. First, compress once from the original: every lossy re-save accumulates damage (generation loss), so editing and re-exporting a JPEG five times degrades it even at constant quality. Second, don't lossy-compress what needs to stay exact — PNG for anything with text or sharp lines, lossless modes for archival copies.
| Use case | Format | Quality | Max width |
|---|---|---|---|
| Hero images, large photos | WebP | 80-85 | 1920 px |
| Product photos | WebP | 85 | 800-1200 px |
| Thumbnails and previews | WebP | 70-75 | 300-400 px |
| Backgrounds, decorative fills | WebP | 65-70 | 1920 px |
| Logos and icons | PNG (or lossless WebP) | lossless | actual display size |
| Email attachments | JPEG / PNG | 80+ | as needed |
The pattern underneath the table: the smaller the display size, the more compression the image tolerates, because there's less detail left to protect. Thumbnails at quality 70 look fine precisely because they're thumbnails.
Images are usually the heaviest thing a page ships — on a typical site they account for roughly half of total page weight. They're also very often the Largest Contentful Paint element, which Google scores as part of Core Web Vitals; "good" means LCP under 2.5 seconds, and a 3 MB hero on a phone network burns most of that budget before the text finishes rendering.
Format choice is the highest-leverage fix because it multiplies everything else: resize to display dimensions, compress to the quality the use case tolerates, serve modern formats with fallbacks, and lazy-load everything below the fold so the hero doesn't queue behind six thumbnails. If you're optimizing thumbnails specifically for click-through rather than speed, our thumbnail A/B testing guide covers the measurement side.
Drop in a PNG, JPEG, WebP, AVIF, GIF, or BMP; pick WebP at quality 80, cap the width, and watch the byte counter fall. Nothing uploads.
Image Compressor →Photographs go out as WebP — or AVIF with a WebP fallback — at quality 75-85, sized to what the layout actually displays. PNG keeps the jobs it's genuinely better at: transparency, hard edges, pixel-perfect graphics. GIF retires. JPEG remains the compatibility layer for email and old software. That sorting, applied once to your asset pipeline, is most of the image-performance work there is.
For photographs on the web, yes. Google's compression studies found lossy WebP files 25-34% smaller than JPEG at equivalent perceptual quality, with the added bonuses of transparency and animation support. JPEG's remaining advantage is universality — every tool since 1992 reads it — so it stays the safe choice for email attachments and old software, not for serving website images.
Effectively yes. Chrome has supported it since 2014, Firefox since 2019, and Safari since 2020, putting coverage above 96% of browsers in use. Unless you must support a decade-old Android browser or an ancient enterprise build, WebP is safe to serve without a JPEG fallback.
Serve AVIF with a WebP fallback if you can generate both: AVIF typically saves about 50% versus JPEG while WebP saves 25-34%, and browser support crossed into the mid-90s after Safari adopted it in 2023. The costs are encoding speed (AVIF is slow to produce) and an older encoding toolchain. If you pick one format, WebP is the pragmatic choice today; AVIF is the better one where your pipeline supports it.
Usually one of two things: the original was already well compressed, or it was a PNG that shrinks beautifully under lossy compression but grows when re-encoded losslessly. Re-compressing an optimized JPEG at high quality can also add overhead. Fix it by choosing WebP output instead of PNG for photos, dropping the quality slider a notch, or resizing — pixels you don't serve are the cheapest bytes you'll ever save.