How to Optimize Images for the Web: Compression, Resizing & Format Selection

The average web page in 2026 weighs approximately 2.5 MB, and images account for roughly 45% of that total. If your site loads slowly, images are almost certainly the primary culprit. The good news: image optimization is one of the highest-impact performance improvements you can make, often cutting page load times in half with no visible loss in quality.

This guide covers everything you need to know about optimizing images for the web: how each format works, when to use which, compression techniques that preserve visual fidelity, responsive image delivery, lazy loading, and a practical workflow you can apply to any project today.

Image Format Comparison: JPEG vs PNG vs WebP vs AVIF vs SVG

Choosing the right format is the single most impactful decision in image optimization. Each format was designed for specific use cases, and using the wrong one can inflate file sizes by 200-500% with no benefit to visual quality.

JPEG (Joint Photographic Experts Group)

JPEG remains the workhorse of web photography. It uses lossy compression that discards visual data the human eye is unlikely to notice, achieving excellent compression ratios for photographic content. JPEG handles gradients, skin tones, and natural scenes remarkably well.

• Best for: Photographs, complex images with many colors, hero images, product photos
• Compression: Lossy only. Quality settings from 0-100 (75-85 is the sweet spot)
• Transparency: Not supported
• Animation: Not supported
• Browser support: Universal (100%)

PNG (Portable Network Graphics)

PNG uses lossless compression, meaning every pixel is preserved exactly as the original. This makes it ideal for graphics with sharp edges, text overlays, and transparency. However, PNG files are significantly larger than JPEG for photographic content, often 5-10x bigger.

• Best for: Screenshots, graphics with text, icons requiring transparency, UI elements
• Compression: Lossless (PNG-8 for simple graphics, PNG-24/32 for full color + alpha)
• Transparency: Full alpha channel support
• Animation: APNG (limited support)
• Browser support: Universal (100%)

WebP

Developed by Google, WebP offers both lossy and lossless compression with significantly smaller file sizes than JPEG and PNG. On average, WebP images are 25-35% smaller than equivalent JPEG files and 26% smaller than PNG files. WebP also supports transparency and animation, making it a versatile replacement for both JPEG and PNG.

• Best for: Everything. Photos, graphics, transparency, animations — WebP handles it all
• Compression: Both lossy and lossless
• Transparency: Full alpha channel support
• Animation: Supported (smaller than GIF)
• Browser support: 97%+ (all modern browsers)

AVIF (AV1 Image File Format)

AVIF is the newest contender, derived from the AV1 video codec. It delivers stunning compression ratios, often 50% smaller than JPEG at equivalent visual quality. AVIF excels at preserving fine detail and handles both photographic and graphic content well. The tradeoff is slower encoding times and slightly less browser coverage than WebP.

• Best for: Maximum compression, high-quality photography, hero images where every KB matters
• Compression: Both lossy and lossless (superior to WebP)
• Transparency: Full alpha channel support
• Animation: Supported
• Browser support: ~93% (Chrome, Firefox, Safari 16.4+, Edge)

SVG (Scalable Vector Graphics)

SVG is fundamentally different from the raster formats above. Instead of storing pixel data, SVG describes shapes, paths, and text using XML markup. This means SVG files scale to any resolution without quality loss and are often incredibly small for simple graphics.

• Best for: Logos, icons, illustrations, charts, simple graphics, anything that needs to scale
• Compression: Already efficient; further optimizable by removing metadata and unused elements
• Transparency: Inherent support
• Animation: Full CSS and JavaScript animation support
• Browser support: Universal (100%)

Compression Techniques: Lossy vs. Lossless

Understanding the difference between lossy and lossless compression is essential to making informed decisions about image quality versus file size.

Lossy Compression

Lossy compression permanently removes data from the image to achieve smaller file sizes. The key is that it targets data the human eye is least sensitive to: subtle color variations, high-frequency noise, and imperceptible details. At quality settings of 75-85, lossy compression typically reduces file size by 60-80% with differences invisible to most viewers.

The most important thing to understand about lossy compression is that recompressing an already-compressed image degrades quality further. Always work from the original, uncompressed source file, and compress only once for the final output.

Lossless Compression

Lossless compression reduces file size without removing any image data. The decompressed image is pixel-for-pixel identical to the original. Lossless tools achieve savings by optimizing how data is encoded: removing unnecessary metadata, improving color palette efficiency, and using better compression algorithms.

For PNG files, lossless compression typically achieves 10-40% file size reduction. For photographs where lossy compression is acceptable, WebP lossless offers roughly 26% smaller files than PNG.

Finding the Right Quality Setting

For JPEG and lossy WebP, the quality setting is the most important parameter. Here is a practical breakdown:

• Quality 90-100: Virtually indistinguishable from the original. Minimal file size savings. Only justified for professional photography portfolios or print-resolution images.
• Quality 80-89: Excellent quality. Differences visible only at extreme zoom. Ideal for hero images and key product photos.
• Quality 70-79: Good quality. Slight softening in high-detail areas. Perfect for blog images, thumbnails, and content images.
• Quality 50-69: Acceptable for small thumbnails and background images where sharpness is not critical.
• Quality below 50: Noticeable artifacts. Only suitable for heavily blurred backgrounds or placeholder images.

Responsive Images: Serving the Right Size to Every Device

A 1920px-wide hero image displayed on a 375px-wide phone screen wastes over 80% of the downloaded data. Responsive images solve this by letting the browser choose the most appropriate image size based on the device viewport and pixel density.

The srcset and sizes Attributes

The srcset attribute provides a list of image files at different widths. The sizes attribute tells the browser how much of the viewport the image will occupy. The browser then selects the smallest image that satisfies the display requirements.

<img
  src="hero-800.jpg"
  srcset="
    hero-400.jpg   400w,
    hero-800.jpg   800w,
    hero-1200.jpg 1200w,
    hero-1920.jpg 1920w
  "
  sizes="
    (max-width: 600px) 100vw,
    (max-width: 1200px) 80vw,
    60vw
  "
  alt="Product showcase image"
  width="1920"
  height="1080"
  loading="eager"
>

In this example, a phone with a 375px-wide viewport would download the 400w image (about 50 KB) instead of the 1920w image (about 350 KB). That is a 7x reduction in data transfer for the same perceived quality.

The picture Element for Format Switching

The <picture> element goes further by allowing you to serve different formats based on browser support. This is the recommended approach for using modern formats like AVIF and WebP with fallbacks.

<picture>
  <source
    type="image/avif"
    srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1200.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 60vw"
  >
  <source
    type="image/webp"
    srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 60vw"
  >
  <img
    src="hero-800.jpg"
    srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 80vw, 60vw"
    alt="Product showcase"
    width="1200"
    height="675"
    loading="eager"
    decoding="async"
  >
</picture>

Browsers that support AVIF will download the smallest AVIF file that fits. Those that do not will try WebP, and the final fallback is JPEG. This progressive enhancement approach ensures every user gets the best experience their browser supports.

Lazy Loading and Core Web Vitals Impact

Lazy loading defers the download of off-screen images until the user scrolls near them. This is one of the simplest yet most effective performance optimizations available: it reduces initial page weight, speeds up rendering, and saves bandwidth for users who never scroll to the bottom of the page.

Native Lazy Loading

Modern browsers support native lazy loading through the loading attribute. No JavaScript required:

<!-- Lazy load below-the-fold images -->
<img
  src="content-image.webp"
  alt="Descriptive alt text"
  width="800"
  height="450"
  loading="lazy"
  decoding="async"
>

<!-- NEVER lazy load above-the-fold (hero) images -->
<img
  src="hero.webp"
  alt="Hero banner"
  width="1920"
  height="1080"
  loading="eager"
  fetchpriority="high"
>

How Images Affect Core Web Vitals

Google's Core Web Vitals directly measure the user experience impact of your images:

• Largest Contentful Paint (LCP): Measures when the largest content element becomes visible. For most pages, this is the hero image. Optimizing your hero image format, size, and loading priority is the single most impactful thing you can do for LCP. Target: under 2.5 seconds.
• Cumulative Layout Shift (CLS): Measures unexpected layout shifts. Images without explicit width and height attributes cause layout shifts as they load. Always specify dimensions in your HTML. Target: under 0.1.
• Interaction to Next Paint (INP): Heavy JavaScript-based image processing can block the main thread. Use the native loading="lazy" attribute instead of JavaScript libraries, and add decoding="async" to prevent image decoding from blocking interactions.

Here is the formula for an optimized hero image that maximizes your LCP score:

• Use AVIF/WebP with JPEG fallback via <picture>
• Set loading="eager" and fetchpriority="high"
• Set explicit width and height attributes
• Add a <link rel="preload"> in the <head> for the hero image
• Serve from a CDN with edge caching

Image CDN Alternatives

An image CDN automates format selection, resizing, and compression on the fly. Instead of manually generating multiple sizes and formats, you append parameters to the image URL and the CDN handles the rest.

How Image CDNs Work

When a browser requests an image from a CDN, the CDN inspects the Accept header to determine which formats the browser supports, then serves the optimal format automatically. Most CDNs also support URL-based transformations:

<!-- Original image URL -->
https://cdn.example.com/images/photo.jpg

<!-- Resized to 400px wide, auto quality, WebP if supported -->
https://cdn.example.com/images/photo.jpg?w=400&auto=format,compress

<!-- With aspect ratio crop and blur effect -->
https://cdn.example.com/images/photo.jpg?w=800&h=450&fit=crop&blur=20

Popular image CDN services include Cloudflare Images, Imgix, Cloudinary, and Bunny Optimizer. For smaller projects, Cloudflare's free tier or self-hosted solutions like Thumbor provide excellent value.

CDN vs. Manual Optimization

Image CDNs are ideal when you have dynamic content or user-uploaded images where manual optimization is impractical. For static sites with a known set of images, manual optimization with build-time tooling gives you more control and eliminates the CDN dependency and cost.

For quick one-off tasks or small projects, our browser-based tools handle the job without any CDN setup:

Practical Image Optimization Workflow

Here is a step-by-step workflow you can apply to any web project, from a personal blog to a high-traffic e-commerce site.

Step 1: Audit Your Current Images

Open Chrome DevTools, go to the Network tab, filter by "Img," and reload the page. Sort by size to find the biggest offenders. Look for images over 200 KB, images being served at dimensions larger than their display size, and images in suboptimal formats (e.g., PNG screenshots of photographs).

Step 2: Choose the Right Format

Apply this decision tree to every image:

• Is it a simple graphic, logo, or icon? → SVG
• Does it need transparency? → WebP (or PNG fallback)
• Is it a photograph and you want maximum compression? → AVIF with WebP/JPEG fallback
• Is it a photograph for general use? → WebP with JPEG fallback
• Is it a screenshot with text? → PNG (or WebP lossless)

Step 3: Resize to the Maximum Display Size

Never serve an image larger than it will be displayed. If your content column is 800px wide, your images do not need to be wider than 1600px (2x for retina). For thumbnails displayed at 200px, generate a 400px version. Use our Image Resizer to batch process multiple images to exact dimensions.

Step 4: Compress

Apply format-appropriate compression. For JPEG and lossy WebP, start at quality 80 and reduce until artifacts become visible, then step back one notch. For PNG, run through a lossless optimizer. For SVG, strip editor metadata and simplify paths using our SVG Optimizer.

Step 5: Implement Responsive Markup

Generate multiple sizes for key images (400w, 800w, 1200w, 1920w is a good default set) and use srcset and sizes attributes. Wrap in <picture> elements for format switching. Always include width, height, and alt attributes.

Step 6: Add Loading Optimizations

Set loading="lazy" on below-the-fold images. Set loading="eager" and fetchpriority="high" on your LCP image. Add decoding="async" to all images. Preload your hero image in the <head>.

Step 7: Validate

Run Google PageSpeed Insights and verify your LCP, CLS, and INP scores. Check the "Properly size images" and "Serve images in next-gen formats" audits. Use WebPageTest for a detailed waterfall analysis of image loading behavior.

When to Use Base64 Inline Images

Base64 encoding converts binary image data into a text string that can be embedded directly in HTML or CSS. This eliminates the HTTP request for the image but increases the document size by approximately 33%.

Use Base64 encoding for:

• Tiny icons under 1-2 KB (the HTTP request overhead is more expensive than the inline data)
• Critical above-the-fold decorative elements that must render without additional requests
• Low-quality image placeholders (LQIP) for progressive loading patterns

Do not Base64-encode images larger than 2-3 KB. The 33% size overhead, inability to be cached independently, and blocking of HTML parsing make it counterproductive for anything beyond tiny assets.

Placeholder Images for Development

During development, you often need placeholder images to test layouts before final assets are available. Rather than hunting for stock photos or using broken image icons, generate properly sized placeholders instantly.

Placeholder images are useful for:

• Prototyping responsive layouts with correct aspect ratios
• Testing lazy loading behavior without downloading real assets
• Wireframing client presentations
• Populating dynamic content templates during development

7 Common Image Optimization Mistakes

Even experienced developers make these errors. Here is what to watch out for:

1. Recompressing already-compressed images: Each round of lossy compression degrades quality. Always compress from the original source.
2. Using PNG for photographs: A 1920px photo saved as PNG might be 3-5 MB. The same image as WebP quality 80 would be 150-250 KB with no visible difference.
3. Missing width and height attributes: Without explicit dimensions, images cause layout shifts as they load, directly hurting your CLS score.
4. Lazy loading the hero image: This delays your LCP element, hurting the most critical performance metric. Use loading="eager" for above-the-fold images.
5. Serving one size to all devices: A 1920px image on a 375px phone wastes bandwidth and slows rendering. Use srcset.
6. Ignoring SVG for icons and logos: Raster icons at multiple resolutions are unnecessary when a single SVG file scales perfectly to any size at a fraction of the file size.
7. Not setting fetchpriority: The fetchpriority="high" attribute tells the browser to prioritize your LCP image over other resources, which can improve LCP by 100-300ms.

Automating Image Optimization in Your Build Pipeline

For production projects, manual optimization does not scale. Here are the most effective ways to automate the process:

Build-time optimization with sharp (Node.js)

sharp is the fastest Node.js image processing library, capable of converting, resizing, and compressing thousands of images in seconds:

import sharp from 'sharp';

// Convert JPEG to WebP and AVIF at multiple sizes
const sizes = [400, 800, 1200, 1920];

for (const width of sizes) {
  // WebP version
  await sharp('original.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}.webp`);

  // AVIF version
  await sharp('original.jpg')
    .resize(width)
    .avif({ quality: 65 })
    .toFile(`output-${width}.avif`);

  // JPEG fallback
  await sharp('original.jpg')
    .resize(width)
    .jpeg({ quality: 80, mozjpeg: true })
    .toFile(`output-${width}.jpg`);
}

Framework integrations

Most modern frameworks include built-in image optimization:

• Next.js: <Image> component with automatic format selection, resizing, and lazy loading
• Astro: <Image> and <Picture> components with build-time optimization via sharp
• Nuxt: @nuxt/image module with provider support for Cloudinary, Imgix, and more
• Vite/Webpack: vite-imagetools or image-webpack-loader for build-time processing

Conclusion: Every Kilobyte Counts

Image optimization is not a one-time task. It is an ongoing practice that should be integrated into your content publishing workflow and build pipeline. The techniques covered in this guide, from format selection and compression to responsive images and lazy loading, collectively reduce page weight by 50-80% on image-heavy pages.

Start with the highest-impact changes first: convert your largest images to WebP, add loading="lazy" to below-the-fold images, set explicit dimensions to prevent layout shifts, and ensure your hero image loads as fast as possible with fetchpriority="high".

The tools referenced in this guide are free and run entirely in your browser. No sign-up, no uploads, no watermarks. Use them to build faster, lighter, more accessible websites.