A modern web page is dominated by images. The HTTP Archive's annual State of the Web report consistently finds that images account for forty to fifty percent of total bytes transferred on the average page, more than HTML, CSS, JavaScript, and fonts combined. The format choice for those images is therefore one of the highest-leverage decisions a web team makes. Pick well and pages load fast, search rankings improve, and bandwidth costs drop. Pick poorly and every other optimization gets diluted.

This guide is a decision-grade reference for choosing image formats on the web. It covers the formats that matter (JPEG, PNG, WebP, AVIF, SVG, and the rare cases for GIF), the rules for picking among them, the production-ready HTML and CSS patterns, and the operational metrics that prove the choices were correct.

The Decision Tree in One Page

Almost every image on the web fits one of five categories. The right format follows directly from the category.

Image TypePrimary FormatFallback ChainNotes
PhotographAVIFWebP, JPEG30 to 50 percent smaller than JPEG
Logo, iconSVGPNGResolution-independent, tiny
Illustration with hard edgesSVG or lossless WebPPNGVector beats raster when the source allows
Screenshot, UI capturePNG or lossless WebPPNGLossless required to avoid text artifacts
AnimationAVIF or video elementWebP, MP4Never use GIF for new content
The remainder of this guide explains why each rule holds, and the production patterns that make the rules operational.

Photographs: AVIF First, WebP Second, JPEG Last

Photographic content (continuous-tone images with smooth gradients, taken with a camera or rendered from a 3D scene) is what JPEG was designed for, and it is also where the modern formats deliver the largest savings.

Why AVIF wins. AVIF derives from AV1's intra-frame coding. On photographic content, AVIF achieves 30 to 50 percent smaller files than JPEG at equivalent perceptual quality, measured against SSIM and Butteraugli. The format ships in every major browser and is the default output of every major image CDN.

Why WebP is still useful. WebP has slightly broader real-world device coverage than AVIF, particularly on older Android devices and corporate browser deployments. WebP also encodes faster than AVIF, which matters in user-uploaded image pipelines.

Why JPEG remains the floor. Universal decoder support. Every browser, OS, image library, and tool reads JPEG. It is the unconditional fallback.

The production HTML pattern is the picture element with three sources, ordered most-modern to most-compatible:

<picture>
  <source type="image/avif"
          srcset="hero-800.avif 800w,
                  hero-1600.avif 1600w,
                  hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="hero-800.webp 800w,
                  hero-1600.webp 1600w,
                  hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="hero-1600.jpg"
       srcset="hero-800.jpg 800w,
               hero-1600.jpg 1600w,
               hero-2400.jpg 2400w"
       sizes="(min-width: 1024px) 1600px, 100vw"
       alt="Description of the image"
       width="1600" height="900"
       loading="lazy" decoding="async" />
</picture>

Several details matter. The width and height attributes prevent Cumulative Layout Shift. The sizes attribute tells the browser how wide the image will be at each viewport size, so it picks the right srcset entry without guessing. The loading="lazy" attribute should be removed or replaced with eager for hero images that are the Largest Contentful Paint candidate.

"The picture element exists because no single image format and no single resolution serves every browser, every device, and every connection. Stop fighting the browser. Give it options and let it choose." Mat Marquis, lead author of the Responsive Images Community Group's picture element specification

Logos and Icons: SVG Above All Else

Vector graphics are the right answer for any image that originated as vector data. Logos, icons, illustrations with hard edges, and most data visualizations all qualify.

The advantages of SVG are concrete:

  • Resolution independence. The same file looks crisp at 16x16 and at 1600x1600.
  • Tiny file size for typical icons (often under 1 KB).
  • CSS-styleable, animatable, and accessible (with proper title and desc elements).
  • Universal browser support.

A production SVG icon should be hand-cleaned or run through SVGO for optimization, served with a long cache lifetime, and inlined into HTML when it is part of the critical render path:

<svg xmlns="http://www.w3.org/2000/svg"
     viewBox="0 0 24 24" width="24" height="24"
     role="img" aria-labelledby="search-title">
  <title id="search-title">Search</title>
  <path d="M10 2a8 8 0 1 0 5.3 14L21 22l1-1-6-6A8 8 0 0 0 10 2z"
        fill="currentColor" />
</svg>

Two patterns to avoid. Embedding raster images inside SVG defeats the format's purpose. Serving SVG with executable script content is a security risk; sanitize SVG that comes from user uploads.

For complex illustrations where vector authoring is not practical, lossless WebP or PNG is the right choice. The lossless formats preserve hard edges without the smearing JPEG produces around text and lines.

Screenshots and UI Captures: Lossless or Nothing

Screenshots have a specific failure mode under JPEG: text and UI edges blur into halos because DCT-based compression assumes smooth tones. PNG, lossless WebP, and lossless AVIF all preserve text crisply.

FormatSample 1920x1080 ScreenshotCompression TypeNotes
PNG220 KBLosslessUniversal support, predictable
Lossless WebP140 KBLossless30 to 40 percent smaller than PNG
Lossless AVIF110 KBLosslessSmallest, slow encode
JPEG q=90180 KBLossyVisible halos around text
JPEG q=7095 KBLossyUnacceptable halos
For documentation, technical content, and any image showing text, the choice is between PNG (universal) and lossless WebP (smaller). The picture element handles both: 
<picture>
  <source type="image/webp" srcset="diagram.webp" />
  <img src="diagram.png" alt="System architecture diagram"
       width="1200" height="800" />
</picture>

Tooling-friendly content sites such as documentation portals or test-prep platforms publish thousands of screenshots; the static-publishing patterns at pass4-sure.us document this PNG-plus-WebP pattern at scale.

Animation: Anything Except GIF

GIF is not an acceptable format for new web content. The reasons are quantitative.

FormatSample 5-second clip, 720x720Color depthDecoder cost
GIF4.2 MB256 colorsLow
Animated WebP480 KBFull colorLow
Animated AVIF320 KBFull color, HDR-capableMedium
MP4 (H.264)280 KBFull colorHardware accelerated
WebM (VP9)240 KBFull colorMostly accelerated
For animations, the right tool is almost always a video element with the autoplay attributes that make it behave like a GIF: 
<video autoplay muted loop playsinline preload="metadata"
       poster="loop-poster.jpg"
       width="720" height="720">
  <source src="loop.av1.mp4" type="video/mp4; codecs=av01.0.04M.08" />
  <source src="loop.h264.mp4" type="video/mp4; codecs=avc1.42E01E" />
  <source src="loop.webm" type="video/webm; codecs=vp9" />
</video>

This pattern delivers 80 to 95 percent smaller files than GIF, plays smoothly on every modern browser, and respects the user's prefers-reduced-motion setting when paired with appropriate CSS.

"GIF was a workaround for 1989. Treating it as a primary delivery format in 2026 is a bandwidth donation to your users' carriers." Jeffrey Friedl, image processing engineer and author of Mastering Regular Expressions

Encoder Settings That Actually Matter

Format choice is necessary but not sufficient. The encoder settings determine whether a chosen format delivers its promise.

JPEG. Use Mozilla JPEG (mozjpeg) rather than libjpeg. Quality 80 to 85 is typically optimal; above 90 the byte cost rises faster than perceptual quality.

# mozjpeg with progressive output
cjpeg -quality 82 -progressive -optimize \
      -outfile photo.jpg photo.png

PNG. Use a modern optimizer (oxipng, pngquant) and prefer Zopfli compression for one-time builds where encode time does not matter.

# oxipng with zopfli for archive-grade PNG
oxipng -o max --strip safe --zopfli photo.png

# pngquant for lossy PNG (still PNG, smaller)
pngquant --quality 70-90 --strip --speed 1 \
         --output photo.q.png photo.png

WebP. cwebp ships with libwebp and produces predictable output. For lossy use quality 80, for lossless use the -lossless flag.

# Lossy WebP
cwebp -q 80 -m 6 photo.png -o photo.webp

# Lossless WebP
cwebp -lossless -m 6 -z 9 logo.png -o logo.webp

AVIF. libavif's avifenc with --speed 6 hits a reasonable encode-speed balance. Production pipelines that can afford CPU should use --speed 4.

# Web-tier AVIF
avifenc --speed 6 --qcolor 50 --qalpha 60 \
        --yuv 420 photo.png photo.avif

# Pro-tier AVIF
avifenc --speed 4 --min 0 --max 30 \
        --yuv 444 --depth 10 photo.png photo.avif

SVG. Run SVGO with care, removing only safe attributes:

svgo --multipass --pretty=false \
     --config='{"plugins":["preset-default",
                "removeDimensions",
                "removeViewBox" 0]}' \
     icon.svg

These settings are starting points, not gospel. The right encoder configuration depends on the source content; benchmark against representative samples before deploying.

Responsive Delivery and Core Web Vitals

Format choice intersects with Core Web Vitals (CWV) at three points.

Largest Contentful Paint (LCP). The hero image is usually the LCP candidate. Optimize it aggressively: AVIF format, correct sizes attribute, fetchpriority="high", and no lazy loading.

<img src="hero.avif" alt="..."
     fetchpriority="high"
     decoding="async"
     width="1600" height="900" />

Cumulative Layout Shift (CLS). Always declare width and height. The browser uses the aspect ratio to reserve space.

Interaction to Next Paint (INP). Heavy images on a page can starve the main thread during decode. Use decoding="async" on non-critical images.

The rest of the responsive pattern follows from the picture element described earlier. For pages with many images (galleries, product grids, content-heavy articles like those at whats-your-iq.com or strangeanimals.info), pair lazy loading with content-visibility CSS to defer offscreen rendering work entirely.

Format-Aware CDN Configuration

A CDN that handles format negotiation automatically eliminates most of the manual work. Cloudflare Polish, Akamai Image Manager, Vercel image optimization, Imgix, and self-hosted libvips or imgproxy all do this. The basic contract is:

  1. Origin stores a single canonical image (typically PNG or high-quality JPEG).
  2. CDN reads the Accept header and returns the best format the browser supports.
  3. CDN caches each format-and-size variant separately.

A reasonable Cloudflare Workers script for hand-rolled negotiation:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const accept = request.headers.get('Accept') || '';
  const url = new URL(request.url);

  let target = url.pathname;
  if (accept.includes('image/avif')) {
    target = target.replace(/\.(jpe?g|png)$/, '.avif');
  } else if (accept.includes('image/webp')) {
    target = target.replace(/\.(jpe?g|png)$/, '.webp');
  }

  const fetchUrl = new URL(target, url.origin);
  return fetch(fetchUrl.toString(), {
    cf: { cacheEverything: true, cacheTtl: 31536000 }
  });
}

Common Mistakes and Their Symptoms

The same five mistakes appear in nearly every poorly performing image pipeline.

  1. Single-format delivery. Serving only JPEG when AVIF and WebP would save 30 percent. Symptom: high LCP scores, large image bytes per page.
  2. Wrong format for content. Photographs in PNG, screenshots in JPEG. Symptom: huge PNGs, blurry screenshots.
  3. Missing width and height. Causes CLS. Symptom: layout jumps as images load.
  4. Lazy-loading the hero. Delays LCP. Symptom: high LCP despite optimized images.
  5. Over-aggressive lossy encoding. Quality 50 JPEGs that look like quality 50 JPEGs. Symptom: visible artifacts on photographs.

Track image format distribution, average bytes-per-image, and Core Web Vitals together. A regression in any of the three is a regression in the others; the metrics covary.

A Practical Default for 2026

For teams without time to over-optimize, this set of defaults captures most of the available wins:

  • Photographs: AVIF, WebP fallback, JPEG floor, served via picture element.
  • Logos and icons: SVG, optimized with SVGO, inlined when in the critical render path.
  • Screenshots: PNG or lossless WebP.
  • Animation: video element with H.264 and AV1 sources.
  • Always: width and height attributes, srcset and sizes for responsive, decoding="async" on non-critical images, fetchpriority="high" on the LCP image.

These rules are not new and not surprising. They are the same defaults the Chrome team, the Web Almanac authors, and every major image CDN converge on. The reason the rules are repeated is that they are unevenly applied. Sites that follow them consistently outperform sites that do not, on every measurable metric.

For deeper context on specific format trade-offs, the SVG vs PNG vs JPG guide and the mastering image compression guide on this site cover encoder tuning and format-specific edge cases in more detail.

Edge Cases That Trip Up Image Pipelines

Even disciplined pipelines run into recurring edge cases. The five worth naming explicitly:

Wide-gamut content on narrow-gamut displays. Modern phone cameras capture in Display P3. Older monitors render only sRGB. Without correct ICC handling, P3 images look oversaturated. Solution: preserve the source profile and let the browser color-manage at display time, or convert to sRGB explicitly during build.

Very large hero images on slow connections. A 4K hero compressed to 800 KB still costs five seconds on a 1 Mbps mobile link. Solution: the sizes attribute should match the actual rendered size; do not serve 4K bytes when the layout caps at 1600 pixels.

User-uploaded content of unpredictable shape. A square upload pipeline that crops portrait images destroys content. Solution: preserve aspect ratio in storage; let the CSS frame the image with object-fit.

SVG with embedded fonts. Fonts that fail to load make text disappear. Solution: convert text to paths in production SVGs, or load the same font that the SVG references.

Animated content with prefers-reduced-motion. Users with vestibular sensitivity should not see auto-playing animation. Solution: gate animation behind a CSS media query that respects the user's preference.

These edge cases hit every team eventually. The right time to handle them is during pipeline design, not during a post-launch incident.

Measurement Loop That Catches Regressions

A working image pipeline produces consistent output. A great image pipeline produces output that improves over time as encoders, formats, and best practices evolve. The difference is the measurement loop.

Three metrics, captured weekly, catch nearly every regression:

  1. Median image weight per page. A surprise jump usually means someone uploaded an unoptimized asset.
  2. AVIF and WebP delivery percentage. A drop indicates CDN configuration drift.
  3. LCP at p75. Field data from the Chrome User Experience Report. The single most important user-facing metric.

Pair these with a budget enforced in CI: fail the build if any image exceeds a per-format size budget. The combination of build-time enforcement and field-time measurement catches problems both before deploy and after.

For content-heavy publishers running this loop, the static-site generators behind sites like whats-your-iq.com and strangeanimals.info demonstrate that the loop scales to thousands of pages without per-page intervention.

A Closing Note on Honest Defaults

The most reliable image strategy is unsentimental. Use the picture element. Default to AVIF, WebP, and JPG fallbacks. Use SVG for vector content. Use PNG for screenshots. Optimize at build time, deliver via a CDN, and measure with Core Web Vitals. The advice has not changed substantially in three years and will not change substantially in the next three. The teams that deliver fast images are the teams that follow these defaults consistently rather than chasing each new format announcement.

References

  1. HTTP Archive, Web Almanac 2024, Media chapter. https://almanac.httparchive.org/en/2024/media
  2. AOMedia, AV1 Image File Format (AVIF) 1.1.0. https://aomediacodec.github.io/av1-avif/
  3. Google Developers, WebP Compression Study. https://developers.google.com/speed/webp/docs/webp_study
  4. W3C, Scalable Vector Graphics (SVG) 2 Recommendation. https://www.w3.org/TR/SVG2/
  5. RFC 9239, Updates to ECMAScript Media Types, IETF, 2022. https://www.rfc-editor.org/rfc/rfc9239
  6. Mozilla, mozjpeg Project Overview. https://github.com/mozilla/mozjpeg
  7. Wang, Z. et al. Image quality assessment from error visibility to structural similarity. IEEE Transactions on Image Processing, 2004. https://doi.org/10.1109/TIP.2003.819861
  8. Google Web Vitals, Core Web Vitals thresholds and image guidance. https://web.dev/articles/vitals