How to Compress Images for Web in 2026 (Quality vs Size, JPG vs WebP vs AVIF)

In 2026 the web image landscape is settled: WebP is universal, AVIF is mainstream for cutting-edge sites, JPG is for legacy support only. PNG is for pixel art and transparency. This guide covers the decisions and concrete numbers.

The 2026 format hierarchy

Format	Compression	Browser support	Use case
AVIF	Best (~50% smaller than JPG)	Chrome, Firefox, Edge, Safari (partial)	Cutting-edge sites, max performance
WebP	Great (~25-35% smaller than JPG)	All major browsers since 2020	Default for new sites
JPG	OK	Universal (since 1992)	Legacy support, fallback
PNG	Lossless, large	Universal	Transparency, pixel art, screenshots
GIF	Inefficient	Universal	Animations only (use animated WebP for new)

For new web work in 2026, default to WebP. Add AVIF for performance-critical pages. JPG only as a <picture> fallback for ancient browsers.

Decision tree

Image for the web
├── Photograph (people, products, scenes)?
│   ├── Performance critical → AVIF (with WebP fallback)
│   └── Standard → WebP (with JPG fallback)
├── Logo, icon, line art?
│   └── SVG (vector — infinite quality, tiny size)
├── Screenshot, UI demo?
│   └── PNG (lossless, sharp text/edges)
├── Pixel art, low-color graphic?
│   └── PNG (lossless preserves color palette)
├── Animation?
│   └── Animated WebP (smaller than GIF) or MP4
└── Hero with transparency?
    └── WebP (transparency supported, smaller than PNG)

Step-by-step: compress a hero image for web

Pickrack Image Compressor workflow:

1. Drop your hero image (typically 4MB+ from your camera or stock site)
2. Resize to 1920px wide (use Image Resizer first if larger)
3. Choose WebP output (or AVIF for cutting-edge)
4. Quality 85 (default for hero — visually lossless)
5. Compare before/after at 100% zoom
6. Download — typical result: 4MB → 80-150KB (95% reduction)

For thumbnails:

• Resize to 400px wide
• Quality 75
• WebP output
• Result: ~10-30KB per thumbnail

Real-world numbers

Same 4MB photograph (4032×3024 from iPhone), output for web:

Format + quality	File size	Reduction	Visible diff
Original (HEIC)	4.0 MB	—	reference
AVIF 85	65 KB	98%	invisible at 100%
WebP 85	95 KB	97%	invisible at 100%
JPG 90	380 KB	90%	invisible at 100%
JPG 80	220 KB	95%	invisible at 100%, slight at 200%
JPG 65	110 KB	97%	visible at 100%
PNG	8.2 MB	-100% (larger)	identical (lossless)

Takeaways:

• WebP at 85% is the sweet spot for new sites — 97% smaller, no visible loss
• AVIF at 85% is even better (98% smaller) but encoding is slower and Safari support is partial
• JPG at 80% is the legacy fallback — still a 95% reduction
• PNG for photos is wasteful — 2x larger than original

Responsive images with <picture>

Modern web doesn't ship one image to all devices. Use HTML <picture> to serve the right size and format:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Hero" loading="lazy" />
</picture>

Browser tries AVIF first, falls back to WebP, then JPG. All three files served from your CDN.

For multi-resolution (mobile vs desktop):

<picture>
  <source media="(max-width: 768px)" srcset="hero-mobile.avif" type="image/avif" />
  <source srcset="hero-desktop.avif" type="image/avif" />
  <img src="hero.jpg" alt="Hero" />
</picture>

Mobile users get a smaller file; desktop users get full resolution. Saves significant bandwidth on mobile.

Compression workflow for production sites

For each image asset:

1. Source: master 4K or original photo in PSD/RAW (keep this — never edit further)
2. Export 1920px PNG as intermediate (lossless reference)
3. Compress 3 outputs:
   • hero.avif (quality 85, ~50KB)
   • hero.webp (quality 85, ~80KB)
   • hero.jpg (quality 80, ~200KB) — fallback
4. Serve via <picture> with the 3 sources

Tools for this workflow:

• Pickrack for ad-hoc one-off compressions
• Squoosh CLI for scripted batch
• Sharp (Node.js) for build-time pipelines (Astro, Next.js, etc.)
• ImageOptim for Mac desktop power users

Core Web Vitals impact

LCP (Largest Contentful Paint) is the time to render the largest visible element on initial load. For most sites, that's the hero image.

Hero image size impact on LCP:

Hero file size	Typical LCP (4G mobile)	Google score
1.5 MB	4.5-6.0s	Poor (red)
500 KB	2.0-3.0s	Needs improvement
150 KB	1.2-1.8s	Good (green)
50 KB	0.8-1.2s	Good (green)

Compressing hero from 1.5MB (poor) to 150KB (good) is one of the biggest single SEO wins available. Most sites have 5-10 minutes of work to do this; the ranking benefit is measurable within weeks.

Common compression mistakes

1. Compressing PNG when you should use JPG/WebP. PNG for photos is wasteful. Convert to WebP (or JPG) for 5-20x smaller files.

2. Using JPG for screenshots. JPG introduces visible artifacts on UI text. Screenshots are sharp/edge-heavy — use PNG (lossless) or WebP lossless.

3. Not resizing before compressing. A 4032px-wide photo compressed to JPG 80% is still 4032px wide — way more than needed for web. Resize to 1920px max first, then compress. Saves another 75% file size.

4. Compressing once but storing twice. Don't re-compress already-compressed JPG. Each compression cycle adds artifacts. Compress from the original, never from a compressed version.

5. Forgetting the fallback. AVIF/WebP are great but Safari has partial AVIF support. Always include a JPG fallback in <picture> or accept that some users see broken images.

6. Using CDN's auto-optimization without verifying. Cloudflare Polish, Vercel Image Optimization, Cloudinary all do automatic compression. Often great. Sometimes too aggressive — verify your hero images look good after their processing.

Bottom line

For new web work in 2026:

• Hero photos: WebP 85% (or AVIF 85% for cutting-edge), with JPG 80% fallback
• Thumbnails: WebP 75%
• Screenshots and pixel art: PNG (lossless)
• Logos: SVG (vector)

Use Pickrack Image Compressor for ad-hoc compression and Image Converter to convert formats. Both are free, browser-side, and unlimited.

For build-time pipelines, install Sharp (Node.js) or Squoosh CLI for scripted batch processing.