Image Compression Guide: Choosing JPG vs PNG vs WebP

Published 2026-04-13 8 min read

Summary (TL;DR)

Last weekend I dropped a 4.2 MB cat photo into Squoosh at WebP quality 80. It came out at 380 KB — a 91% reduction — and I genuinely cannot tell it apart from the original at any realistic screen size. That is lossy compression doing exactly what it should. Every time I forget this, I open a blog and wait three seconds for a 2 MB hero JPG to land over LTE, and the lesson re-arrives on its own.

Choosing an image format is less about finding “the best” one and more about matching the format to a purpose. For continuous-tone photography, lossy formats like JPEG, lossy WebP, and AVIF keep files small with minimal perceptual difference; at similar visual quality, WebP typically produces files roughly 25-35% smaller than JPEG, and AVIF often lands around 40-50% smaller than JPEG depending on encoder settings. For logos, icons, screenshots, and anything where crisp edges or text legibility matter, lossless formats such as PNG, lossless WebP, and TIFF are safer. If you need transparency and animation together, WebP, APNG, and AVIF are the main options. Browser support is broad as of early 2026: WebP has shipped since Chrome 32 (2014), Firefox 65, and Safari 14 (late 2020), and AVIF works in Chrome 85 (August 2020), Firefox 93 (October 2021), and Safari 16 (September 2022) onward. A reasonable baseline is “SVG for vector logos, WebP or AVIF for photos, PNG for screenshots,” with a <picture> fallback to JPEG when you need to support older environments.

Background

Lossy formats (JPEG, lossy WebP, AVIF) reduce file size by discarding information the human visual system is less sensitive to. Two core techniques drive this: quantization, which rounds frequency-domain coefficients more aggressively for higher spatial frequencies, and chroma subsampling, which stores color channels at lower resolution than luminance. A 4:4:4 setting preserves chroma at full resolution, while the more common 4:2:0 reduces chroma by half in both directions. That default is fine for most photos, but it can blur colored text edges, especially red and blue type on a dark background.

JPEG, standardized in 1992, uses a block-based Discrete Cosine Transform (DCT) applied to 8x8 pixel blocks. WebP builds on the intra-frame techniques of the VP8 video codec, and AVIF uses the intra-frame toolset of AV1. Both are therefore substantially more modern than JPEG in how they predict, transform, and quantize image data, with larger block sizes, directional prediction, and better entropy coding. PNG is a different animal: it is a lossless format using the deflate compression family, with built-in support for alpha transparency and palette-based indexed color. PNG never discards data, but for photographic content that purity comes at the cost of much larger files.

A related concept is progressive decoding. Progressive JPEG and interlaced PNG let a viewer see a low-resolution version of the image immediately and refine it as more bytes arrive. WebP and AVIF generally decode as single passes today, which matters mostly for very large images or slow connections. SVG, finally, is not a compressed raster format at all but a vector description; file size is driven by the number of shapes and the compression of the text itself (gzip and brotli are highly effective on SVG source).

Data / Comparison

FormatLossyLosslessTransparencyAnimationTypical photo compression2025 browser support
JPEGYesNoNoNoAround 10:1All browsers
PNGNoYesYesAPNG extensionRoughly 2-3:1All browsers
WebPYesYesYesYes~25-35% smaller than JPEGSafari 14 (2020) and newer, effectively universal
AVIFYesYesYesYes~40-50% smaller than JPEGChrome 85+, Firefox 93+, Safari 16+
GIFYes (palette, 256 colors)No1-bit onlyYesPoor for photosAll browsers

Treat these numbers as general tendencies. Real-world compression depends heavily on source content, encoder, preset, and target quality. The same JPEG at quality 85 and quality 60 can differ by 3-4x in size, and AVIF’s efficiency advantage narrows when you use fast presets. Benchmarks published by Google and Mozilla between 2019 and 2023 reported WebP savings of around 26% to 34% versus JPEG at equivalent SSIM, and AVIF savings around 40% to 50% versus JPEG — but those ranges assume slow-preset encoders and tuned quality targets, not the one-click defaults of most editing apps.

Another dimension is encode and decode cost. JPEG decodes in fractions of a millisecond on any device. WebP is close. AVIF decode is CPU-heavier, and AVIF encode at high-quality presets can take seconds per image. That cost profile is fine for a build-time asset pipeline but awkward for live user-generated content where a server re-encodes every upload on the hot path.

Real-world Scenarios

Scenario 1 — Blog thumbnails and hero images. I recently audited my own site and found a hero image shipping at 1.8 MB. Re-exporting to WebP quality 82 brought it to 210 KB, and the page’s Largest Contentful Paint dropped from 2.4 s to 1.1 s on a throttled 4G profile in Lighthouse. Default to WebP as the primary format and let a <picture> element serve JPEG as a fallback for very old environments. Always resize the exported image to match the actual CSS display width; serving a 3000-pixel-wide photo into a 600-pixel container wastes bandwidth regardless of format.

Scenario 2 — Logos and icons. If you have a vector source, export SVG first. I once reviewed a landing page where a red brand logo had been exported as JPEG at quality 75; the red edges bled into a pink halo around every glyph. Chroma subsampling at 4:2:0 ruins red-on-dark edges before it ruins almost anything else. If only raster art is available, pick PNG or lossless WebP. Treat lossy compression on logos as a red flag, not an optimization.

Scenario 3 — Screenshots and UI captures. Screenshots should default to PNG. Browser chrome, code snippets, and CJK fonts all show JPEG artifacts strongly — I learned this after a doc reviewer flagged “blurry monospace font” on two consecutive PRs. If you must shrink the file, reach for pngquant (on macOS, brew install pngquant) to drop the palette to 256 colors; UI screenshots almost never show the difference, and the file often shrinks 4-6x. For docs sites, consider pairing PNG with CSS responsive image markup so retina displays receive 2x assets while older screens download the 1x version — that usually saves more bytes than switching formats.

Scenario 4 — Archival of source material. For originals you might reprocess later (photography masters, raw scans, product shots), keep a lossless copy such as TIFF or lossless WebP in cold storage and derive lossy delivery variants on demand. Re-compressing a lossy JPEG repeatedly degrades quality each cycle (“generation loss”), so you want a clean source to return to.

Common Misconceptions

“PNG is always the highest quality.” It is lossless, which means perfect reproduction, but for photographs that purity translates into files several times larger than necessary. On mobile, multi-megabyte photos hurt perceived load time and Core Web Vitals.

“WebP does not work in all browsers.” Since Safari 14 in late 2020, WebP has been supported in every mainstream browser. If legacy support is genuinely required, a <picture> element with a JPEG fallback is a clean solution.

“AVIF is magical.” Compression efficiency is excellent, but encoding is significantly slower than JPEG or WebP. On my M2 MacBook Air, avifenc --speed 4 takes 5-9 seconds for a single 2400×1600 photo; at --speed 0, expect 30 s or more. Decoding on older mobile devices can also be a concern. AVIF fits batch pipelines and build-time optimization better than re-encoding every user upload on the hot path.

“Just use JPEG.” That was reasonable until around 2015, but modern WebP and AVIF generally give smaller files at comparable quality with universal or near-universal support. New pipelines should treat WebP as the baseline rather than JPEG.

“Higher quality settings are always worth it.” Above roughly quality 85 for JPEG or WebP, file size grows faster than perceptual quality. Viewers rarely notice the difference between quality 85 and 95, but the file may be twice as large. Measure with a perceptual metric (SSIM, butteraugli) rather than trusting the quality slider as a linear scale.

“Resizing does not matter if I compress well.” The biggest single wins in image delivery usually come from sending appropriately sized images rather than from compression tuning. An 800-pixel-wide WebP is almost always lighter than a 3000-pixel-wide WebP, regardless of quality setting, because you are removing pixels rather than approximating them.

Checklist

  1. Is the source vector? If yes, save as SVG.
  2. Do you need transparency?
    • Yes and the content is photographic: lossy WebP with alpha or AVIF.
    • Yes and the content is a logo or icon: PNG or lossless WebP.
  3. Do you need animation? Animated WebP, APNG, or AVIF. GIF’s 256-color palette is poor for photos.
  4. Is the content photographic or gradient-heavy? Default to lossy WebP, and add AVIF where bandwidth matters.
  5. Is the content a screenshot or text-heavy UI? Prefer PNG or lossless WebP.
  6. Do you need maximum compatibility? Use a <picture> element with AVIF → WebP → JPEG sources in that order.

You can try these trade-offs directly in the Patrache Studio image compressor referenced in relatedToolUrl. Images are usually part of a larger asset pipeline, so reading the companion guides helps: PDF Merge & Split in Browser covers what happens when your images end up inside contracts or scanned bundles, and QR Code Security is worth reading if your images include scannable QR codes on product packaging or posters.

References

Related Tool

tools.patrache.studio/image/compress/