Four differences first
| Format | Lossless | Alpha | Animation | Typical use |
|---|---|---|---|---|
| JPEG | Lossy | No | No | Photos, continuous tone |
| PNG | Lossless | Yes | No | Screenshots, line art, icons, transparency |
| WebP | Both | Yes | Yes | General web, smaller size |
| AVIF | Both | Yes | Yes | Smallest size, slower encode |
| GIF | Lossy (256 colours) | Yes | Yes | Simple animation, limited palette |
| SVG | Vector | Yes | Yes | Icons, logos, line art |
Where to set quality
- Photos: JPEG quality 75–85 is usually visually lossless; at the same look WebP is ~25–35% smaller than JPEG, AVIF another 20–30%;
- Screenshots / UI: use PNG or lossless WebP so text edges stay crisp;
- Icons / line art: prefer SVG, infinitely scalable;
- Animation: use video instead of GIF when you can — smaller and sharper.
Common pitfalls
- Re-compression accumulates loss: saving JPEG repeatedly degrades it; keep a lossless original;
- Transparency to JPEG: JPEG has no alpha, so transparent areas turn black or white;
- Ignoring EXIF: photos carry capture time and location that can leak; strip it before publishing;
- AVIF is slow to encode: great at build time, poor for real-time upload conversion.
Try it
Watermark and control export quality: Image watermark.
Real-world cases: three wrong image format choices
- Photos saved as PNG: a photo PNG can run to megabytes, while WebP / AVIF cuts a large fraction. Use lossy formats for photos and keep PNG / SVG for icons and line art.
- Icons exported as JPG: visible noise and jagged edges, and transparency is lost. Prefer SVG for icons; for bitmaps use PNG or transparent WebP.
- Changing format but not size: shipping a 4000px original to a phone costs far more than the encoding gains. Pair it with
srcsetto serve viewport-appropriate widths.
FAQ
WebP or AVIF? AVIF compresses better but encodes slower with thinner support; use picture to offer AVIF with a WebP fallback. How small should images be? Size them for display; a hero image within 200KB is usually fine — do not sacrifice quality for weight. Keep the originals? Yes — they are the only source for re-export, so compressed outputs must be reproducible. How do I avoid layout shift? Set width / height or a fixed aspect ratio so space is reserved while loading.
Delivery pipeline and tooling
Image weight problems are rarely solved ad hoc; embed the rules in the build.
- Generate sizes automatically: produce several width variants during build or upload and select by viewport with responsive attributes instead of shipping originals.
- Make the fallback explicit: use markup that offers both modern and legacy formats and lets the browser choose, rather than detecting in script and loading later, which adds a round trip.
- Budget the weight: set a total image weight ceiling per key page and fail the build when exceeded — an automated check beats a review reminder.
- Bound lazy loading: never lazy-load the hero image or first paint is delayed; delay only below-the-fold images and reserve their dimensions to avoid layout shift.
- Mind decode cost: small does not mean cheap to decode — oversized resolutions cost memory and decode time on mobile even when well compressed. Sizing to display remains the single most important rule.
Review and versioning
Compressed outputs should be script-generated rather than hand-uploaded so exports are reproducible. Archive originals separately and record each asset's purpose and licensing.
Trade-offs at small sizes
For icons and thumbnails the format difference is often only a few kilobytes, so prioritise sharpness and consistency over shrinking further. Squeezing a small image to minimum quality blurs it on high-density displays and costs more than it saves.