Images are still the largest contributor to page weight on most websites, and the difference between a thoughtfully optimized image pipeline and a careless one is routinely several hundred kilobytes per page — enough to meaningfully affect load time and Core Web Vitals scores on its own, independent of any other optimization.
Lossy vs Lossless: What's Actually Being Thrown Away
Lossless compression (PNG, and lossless WebP) reduces file size without discarding any image data — decompressing returns pixel-for-pixel the original. This is why PNG is the right choice for anything that needs to stay pixel-perfect: screenshots with text, logos, icons, diagrams with hard edges.
Lossy compression (JPEG, lossy WebP) permanently discards information the algorithm predicts will be least noticeable to human vision — subtle color gradations, fine detail in busy areas — in exchange for dramatically smaller files. For photographs, this tradeoff is usually invisible at reasonable quality settings, because natural photos already contain the kind of gradual variation lossy algorithms are good at approximating. For flat-color graphics or text, the same algorithm produces visible artifacting (blurring, "ringing" around hard edges) because there's no gradual variation to approximate — which is exactly why a screenshot saved as JPEG often looks noticeably worse than the same screenshot as PNG, at a similar file size.
Choosing a Format
JPEG — the safe default for photographs. Universally supported, mature tooling, predictable quality-vs-size tradeoff via a single quality parameter.
PNG — required for anything needing transparency or pixel-perfect edges: logos, icons, UI screenshots, diagrams. Expect meaningfully larger files than JPEG for equivalent visual complexity, since it's not discarding any data.
WebP — generally the better choice over both when you can use it: it supports both lossy and lossless modes in one format, plus alpha transparency (unlike JPEG), and typically produces 25–35% smaller files than JPEG at equivalent visual quality, or smaller than PNG in lossless mode. Support is now effectively universal across modern browsers, which removes the main historical objection to using it as a default.
AVIF — newer still, often beats WebP on compression ratio, but encoding is slower and support, while growing, isn't yet as universal — worth using with a fallback (<picture> with WebP/JPEG alternates) rather than as a sole format today.
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="Fallback for browsers supporting neither">
</picture>
What "Quality 80" Actually Means
Lossy compression quality settings (typically 0–100) control how aggressively the algorithm approximates fine detail — but the relationship to perceived quality isn't linear. The jump from quality 100 to 90 is often visually undetectable while cutting file size substantially, because quality 100 includes redundant precision most viewing conditions can't actually distinguish. Below roughly quality 60–70, artifacts start becoming visible to most viewers, and the file-size savings per additional quality point drop off. In practice, quality 75–85 is the sweet spot for most photographic web content — meaningfully smaller than "quality 100" with no visible difference in a typical browsing context.
Resizing Matters More Than Compression Settings
A photo captured at 4000×3000 pixels and merely quality-compressed for a 400px-wide thumbnail slot is wasting the overwhelming majority of its data on resolution nobody will ever see — no compression setting fixes that; the fix is resizing to the actual display dimensions (accounting for retina/high-DPI displays, typically 2x the CSS pixel size) before compression, not after. This is consistently the single biggest, easiest win in image optimization, and it's routinely skipped in favor of chasing compression quality settings that matter far less by comparison.
A Practical Workflow
- Resize to the actual maximum display dimensions needed (2x for high-DPI support), not the source camera/export resolution.
- Pick format by content type: JPEG/WebP for photos, PNG/WebP for anything needing transparency or hard edges.
- Compress at quality 75–85 for photographic content as a starting point, adjusting down only if the size still doesn't hit your target and up only if artifacts become visible.
- Serve modern formats with fallbacks via
<picture>, and always set explicitwidth/heightattributes to avoid layout shift while images load.
For a quick one-off — compressing a screenshot before attaching it somewhere, or shrinking a photo before uploading it — our Image Compressor adjusts quality and maximum dimensions using the browser's Canvas API directly, so nothing is uploaded to a server in the process.
Summary
- Lossy compression (JPEG, WebP) discards data predicted to be visually unimportant — great for photos, poor for flat graphics and text; use lossless PNG/WebP for those instead.
- WebP is generally the better default over both JPEG and PNG today, given near-universal browser support and consistently smaller files at equivalent quality.
- Quality settings above ~85–90 mostly add file size without visible benefit; quality below ~60–70 starts introducing visible artifacts — the useful range is narrower than the 0–100 scale suggests.
- Resizing to actual display dimensions before compressing is usually a bigger win than tuning compression quality — check this first.