Cut Image Bytes 40–55%: Web Image Formats for Designers & Engineers

Use AVIF for photographs and complex imagery, SVG for icons, logos and interface graphics, and WebP as the universal fallback wherever transparency or animation matters. PNG earns its place only for lossless masters or text-heavy screenshots, while GIF survives mainly as a legacy curiosity. Every format should be served through a picture element with srcset, ideally routed through a CDN transform layer rather than exported by hand.

TL;DR:

• Using AVIF can reduce image file sizes by 40 to 55% compared to JPEG, significantly improving page load times and Core Web Vitals scores.
• Browser support for AVIF is widespread among modern browsers, but fallback to WebP and JPEG remains necessary for older or less compatible environments.
• WebP offers reliable, near-universal support with near-optimal compression and supports transparency and animation, making it the best fallback format.
• JPEG should only be used as a last resort for legacy compatibility, with a quality setting between 75 and 85, and should be avoided for images requiring transparency or sharp detail.
• Implementing CDN-driven image transforms, responsive srcset, and priority preloading for the largest content images provides the highest return on performance improvements.

Table of Contents

• TL;DR checklist: what to use and what to do first
• AVIF: the compression leader and its real costs
• WebP: the format that just works everywhere
• JPEG: still the safest fallback, if you encode it properly
• PNG: when lossless actually means lossless
• SVG: the right answer for icons, logos and UI graphics
• GIF, APNG and animated alternatives worth using instead
• Which legacy formats to retire from your workflow
• How to build responsive delivery with srcset, sizes and picture
• Which performance settings actually move the needle
• Tooling and workflow for image pipelines at scale
• How Medway Web Design implements image pipelines on client projects
• Get your image pipeline audited and rebuilt properly
• Why format adoption speed depends on team size, not ambition
• Sources

TL;DR checklist: what to use and what to do first

If you need to make a decision this afternoon, work from this list rather than re-reading every section below.

Pick by use case:

• Hero photo or product image: AVIF first, WebP second, JPEG last resort.
• Logo or icon: SVG, inclined or externally referenced depending on reuse.
• UI screenshot with text: PNG or lossless WebP, never a heavily compressed JPEG.
• Short looping animation: animated WebP or a muted MP4/WebM, not GIF.
• Legacy CMS export or client-supplied TIFF/BMP: convert on ingestion, archive the original.

Fallback chain to build into every template:

AVIF → WebP → JPEG/PNG, ordered inside a picture element so unsupported browsers silently drop to the next source.

Immediate operational steps:

1. Turn on CDN image transforms (Cloudinary, Cloudflare Images, or Imgix) so variants generate on request instead of being exported manually for every breakpoint.
2. Identify the Largest Contentful Paint (LCP) image on your key templates and preload it with fetchpriority="high", never loading="lazy".
3. Add a picture element with AVIF and WebP sources to your three highest-traffic templates before touching anything else.

That order matters. Fixing the LCP image alone often moves the needle more than converting every asset on the site.

AVIF: the compression leader and its real costs

AVIF typically shrinks files by 40 to 55% compared with JPEG and around 20% versus WebP at equivalent visual quality, which makes it the strongest single format change most sites can make. That saving compounds because Images account for roughly half the transferred bytes on the average page.(https://webvitals.tools/blog/how-to-optimize-images-for-web/), so a format swap on hero and product imagery often does more for load times than any amount of code-splitting.

Statistic Callout: Converting a JPEG-heavy page to AVIF commonly improves LCP by 1 to 3 seconds, which is frequently the difference between passing and failing Google’s Core Web Vitals thresholds.

The catch is encoding cost. AVIF’s compression algorithm is considerably more CPU-intensive to encode than WebP or JPEG, which is fine for a handful of images but painful if you’re batch-processing thousands of product photos on a build server. The practical fix is to offload encoding rather than avoid the format:

• Let a CDN transform layer encode AVIF on demand and cache the result, rather than pre-generating every variant at build time.
• If you must encode in CI, run AVIF jobs asynchronously and don’t block deploys on them.
• Reserve AVIF-as-primary for image-heavy pages (galleries, product listings, editorial features) where the byte savings are largest.

Browser support for AVIF now covers the overwhelming majority of traffic across modern Chromium, Firefox and Safari releases, but the format still needs a fallback for older browsers and some in-app webviews. The deployment pattern is a picture element listing AVIF first, WebP second, and JPEG last, letting the browser pick the first source type it understands.

WebP: the format that just works everywhere

WebP is the format you reach for when you need something that behaves predictably across almost every browser and every use case, without AVIF’s encoding overhead. It supports both lossy and lossless compression, alpha transparency, and animation in a single container, which is more flexibility than JPEG or PNG offer on their own.

Compared with JPEG, WebP typically produces files 25 to 35% smaller at similar visual quality, and lossless WebP frequently beats PNG on size while preserving full pixel fidelity. That combination makes it the sensible default fallback behind AVIF rather than a format you only use when AVIF isn’t available.

Reach for WebP over AVIF as your primary format when:

• You’re encoding at scale without a CDN transform layer and need faster encode times.
• You need transparency support but can’t guarantee AVIF alpha handling in your target browsers.
• You’re working with a build pipeline that already has mature WebP tooling but limited AVIF support.
• The image is small enough that the extra AVIF saving is marginal in absolute bytes.

WebP support across current browsers is close to universal, which is precisely why it belongs in every fallback chain even on an AVIF-first site.

JPEG: still the safest fallback, if you encode it properly

JPEG remains the final safety net in the fallback chain, not because it’s efficient, but because virtually nothing on the modern web fails to decode it. Keep it in the toolchain for legacy CMS exports, email-embedded images, and any system that doesn’t understand picture element fallbacks.

When JPEG is genuinely the format in use, encoding settings matter more than most teams assume:

• Target a quality setting of 75 to 85 for photographic content; anything above 85 adds file weight with barely perceptible quality gains.
• Use progressive encoding rather than baseline JPEG, so the image renders a low-resolution preview before the full file arrives.
• Avoid JPEG entirely for flat-colour graphics, screenshots with text, or anything requiring transparency; it wasn’t designed for that content and the artefacts show.

Pro Tip: Run a batch of your existing JPEGs through mozjpeg at quality 80 before assuming you need a full format migration. The difference between a default export and a properly tuned mozjpeg pass is often larger than the gap between JPEG and WebP at matched settings.

JPEG is the wrong choice whenever you’re exporting a new asset from scratch and have AVIF or WebP tooling available. Its only remaining justification is compatibility, not quality or efficiency.

PNG: when lossless actually means lossless

PNG’s job is narrow but non-negotiable: pixel-perfect reproduction with no compression artefacts. That matters for UI screenshots containing text, diagrams with sharp edges, and any master asset you’ll re-export later.

Distinguish between the two common variants before choosing. 8-bit PNG (indexed colour, up to 256 colours) suits simple graphics and icons where file size matters more than colour depth. 24-bit PNG (true colour with optional alpha) is the one you need for photographic-quality transparency or detailed screenshots, at a considerably larger file size.

Before defaulting to PNG, check whether lossless WebP does the same job smaller. It usually does. Where PNG is unavoidable:

• Run output through oxipng or pngcrush to strip metadata and recompress without quality loss, typically saving 10 to 30% with zero visual change.
• Keep PNG for master files you’ll re-edit, and for screenshots containing small text, where any compression artefact becomes visible immediately.
• Export web-facing copies as WebP or AVIF from that PNG master, rather than serving the PNG directly.

PNG remains correct for archival masters and text-heavy screenshots. It’s rarely correct as the only format shipped to a browser.

SVG: the right answer for icons, logos and UI graphics

Vector graphics don’t have a “compression versus quality” trade-off the way raster formats do, because SVG describes shapes mathematically rather than storing pixels. That’s why it scales cleanly from a favicon to a full-bleed hero graphic without any loss of sharpness, and why it should be the default for logos, icons and most illustrative UI elements. If you’re deciding between a vector or raster export for a brand mark, our guide on logo file formats for websites covers that decision in more depth.

SVG is also styleable with CSS, which means a single icon file can change colour on hover without a second asset. Inline SVGs directly in HTML when you need that styling control or when the icon is unique to one page; reference external .svg files when the same graphic repeats across many templates and you want browser caching to do the work.

Two practices keep SVGs lean and safe:

• Run every SVG through SVGO before deployment to strip editor metadata, redundant groups and unnecessary precision, often cutting file size by half or more.
• Sanitise any SVG uploaded by a third party. SVG files can contain embedded scripts, so treat user-submitted vectors as untrusted content and strip scriptable elements server-side.

Pro Tip: If a design tool exports an SVG with dozens of nested groups and inline styles, don’t ship it as-is. Run it through SVGO’s CLI with default settings first. It’s a thirty-second step that regularly halves file weight.

GIF, APNG and animated alternatives worth using instead

GIF’s colour palette limit (256 colours) makes it a poor choice for anything beyond simple, low-detail loops, and its file sizes for genuine animation are consistently larger than modern alternatives. APNG and animated WebP both offer full colour depth and better compression than GIF for the same visual result, and animated AVIF is emerging as an even smaller option where tooling supports it.

For anything longer than a few seconds or containing more than a handful of frames, stop thinking in image formats altogether and use a short muted MP4 or WebM video instead. Video codecs compress motion far more efficiently than any frame-based image format, often at a fraction of the byte weight for the same duration.

Whichever format you choose, respect accessibility basics: avoid autoplay on anything with rapid flashing, provide pause controls for looping content longer than a few seconds, and honour the prefers-reduced-motion media query so users who’ve requested less motion don’t get an animated hero forced on them.

Which legacy formats to retire from your workflow

JPEG 2000, TIFF, BMP and ICO occasionally still turn up in client asset folders, but none belong in a production web pipeline. JPEG 2000 never achieved consistent browser support despite decent compression. TIFF and BMP are essentially uncompressed or lightly compressed, producing files far larger than any modern web format for the same content. ICO survives only because Windows favicon conventions still reference it in some contexts.

The practical approach when a client hands over legacy files:

• Convert to a modern format (AVIF, WebP, or SVG for vector-based ICO sources) immediately on ingestion, never at publish time.
• Archive the original TIFF or BMP master somewhere off the delivery path, in case a print or high-resolution reprint need comes up later.
• For favicons specifically, generate a modern PNG/SVG set alongside a single legacy ICO purely for older browser compatibility, rather than relying on ICO as the primary asset.

How to build responsive delivery with srcset, sizes and picture

Format choice only pays off if the browser also receives the right size of that format for the viewport it’s rendering on. That’s what srcset, sizes and picture solve together, and the pattern below is the one worth memorising rather than looking up each time.

1. Generate multiple resolutions of each master image (commonly 480w, 768w, 1200w, 1920w) through a CDN transform or build step, never by manual export.
2. Write the srcset attribute listing each file with its width descriptor, letting the browser choose based on viewport and device pixel ratio.
3. Add a sizes attribute describing how much of the viewport the image will occupy at each breakpoint, so the browser can calculate which srcset candidate actually applies.
4. Wrap format fallbacks in a picture element, ordering source elements AVIF first, WebP second, with a plain img as the final fallback.
5. For art direction (swapping a tightly cropped portrait image on mobile for a wide landscape crop on desktop), use the media attribute on each source rather than relying on CSS cropping alone.

A minimal but production-ready pattern looks like this:

<picture>
<source type="image/avif" srcset="hero-480.avif 480w, hero-1200.avif 1200w, hero-1920.avif 1920w" sizes="100vw">
<source type="image/webp" srcset="hero-480.webp 480w, hero-1200.webp 1200w, hero-1920.webp 1920w" sizes="100vw">
<img src="hero-1200.jpg" srcset="hero-480.jpg 480w, hero-1200.jpg 1200w, hero-1920.jpg 1920w" sizes="100vw" alt="Descriptive text" fetchpriority="high">
</picture>

Common breakpoint widths and their typical role on a hero image:

Pairing this with a sizes value that matches your actual CSS layout is what stops browsers downloading an oversized image on mobile. If your layout shifts crop or composition between breakpoints rather than just scaling, our guide on responsive design patterns covers how media-based art direction slots into a wider responsive strategy.

Which performance settings actually move the needle

Most sites chase dozens of micro-optimisations when four settings account for the bulk of measurable improvement.

Quality targets: Encode photographic content at 80 and text-containing or high-detail imagery at 85. Going lower saves negligible bytes and starts introducing visible artefacts around 70 for most photographic content; going higher wastes bandwidth for imperceptible gains.

Never lazy-load your LCP image. This is the single most common mistake teams make when they roll out loading="lazy" site-wide. If the browser has to discover an image before it can start downloading it, you’ve delayed the paint that Core Web Vitals is measuring you on. Instead:

• Add fetchpriority="high" to the hero or LCP-candidate image so the browser prioritises it in the fetch queue.
• Use a <link rel="preload"> for that same image in the document head if it’s referenced via CSS background rather than an img tag.
• Apply loading="lazy" only to images below the fold, where deferring the request genuinely saves bandwidth without affecting perceived load speed.

Statistic Callout: Optimising images through format, responsive delivery and lazy loading together is frequently the highest-ROI single change available to improve LCP, ahead of most JavaScript or server-side interventions.

Reserve aspect ratio space with explicit width and height attributes (or a CSS aspect-ratio) on every image, lazy-loaded or not. This prevents layout shift as images pop in, which is what Cumulative Layout Shift actually measures.

Pro Tip: If you can only fix one thing today, audit your homepage and product templates for a lazy-loaded hero image. It’s astonishingly common, and removing loading="lazy" from that single element often produces a bigger LCP win than an entire afternoon of format conversion.

Tooling and workflow for image pipelines at scale

Manually exporting AVIF, WebP and JPEG variants at four breakpoints for every image on a growing site becomes untenable within a few months. Two operational models solve this, and most mature teams end up using both.

CDN transforms (Cloudinary, Cloudflare Images, Imgix and similar services) generate format and size variants on request from a single master asset, caching the result at the edge. This is the recommended approach for sites of meaningful traffic, because it removes the need to pre-generate every combination of format and width, and it means a new breakpoint or format (animated AVIF, say) can be added without touching a single existing asset. If you’re running WordPress specifically, our CDN setup guide walks through getting this live quickly.

Build-time tooling still has a role for smaller sites or for quality assurance. Running Squoosh, libavif, or mozjpeg in a CI pipeline lets you check that a new asset actually meets your quality and size targets before it merges, even if production delivery happens through a CDN.

Whichever model you choose:

• Measure LCP before and after any format migration on a real device, not just Lighthouse on desktop.
• Track bandwidth costs alongside encoding costs. CDN transforms shift cost from storage to compute; that trade-off usually favours the CDN at any meaningful traffic volume.
• Treat image SEO as part of the same workflow rather than a separate task. Descriptive filenames and alt text cost nothing extra once the format pipeline is already in place.
• Prefer on-demand CDN transforms over exhaustive pre-generation once your asset library exceeds a few hundred images.

How Medway Web Design implements image pipelines on client projects

Our approach on client builds follows the single-master-asset pattern throughout this guide: one high-resolution source per image, transformed into AVIF, WebP and fallback variants through a CDN layer rather than exported by hand for every breakpoint. That keeps the asset library manageable as a site grows and means format upgrades (adding animated AVIF support, say) don’t require reprocessing existing content.

On projects where image weight was the dominant performance bottleneck, moving from unoptimised JPEG exports to an AVIF-first picture pattern has typically produced the LCP and bandwidth improvements the format benchmarks above would predict, alongside the responsive srcset and lazy-loading practices covered earlier. We treat an image audit as a standard early step in any website speed optimisation engagement, not an afterthought bolted on after launch.

Get your image pipeline audited and rebuilt properly

A specialist agency is the alternative to guessing your way through format conversions one image at a time. Where a generic checklist tells you what AVIF and WebP can do, the actual pipeline, CDN transforms, picture fallbacks and all can be integrated into your existing site without you having to touch a single export setting yourself.

The process typically starts with a site audit that flags which templates are shipping oversized or wrongly formatted images, then maps out a staged rollout: CDN transform setup, picture/srcset implementation on key templates, and LCP measurement before and after. That’s the same process outlined in our guide to custom web design for small businesses, applied specifically to image performance rather than a full rebuild.

If your site’s hero images are still shipping as unoptimised JPEGs, or your last redesign never touched the image pipeline, get in touch and we’ll scope an audit against your actual templates and traffic.

Why format adoption speed depends on team size, not ambition

Small teams overestimate how much they need an AVIF-first pipeline on day one. If you’re shipping fewer than a few hundred images and don’t have CI infrastructure already, WebP with a solid picture fallback gets you most of the performance benefit with a fraction of the operational overhead, and you can layer AVIF in later without re-architecting anything.

Larger organisations with image-heavy catalogues face the opposite problem: the cost of not investing in AVIF and CDN transforms compounds every time the catalogue grows, because manual export processes that worked at 500 products collapse at 50,000. The right question isn’t “is AVIF worth it”, it’s “how many images am I adding next quarter, and does my current pipeline survive that”. For most teams past a few thousand assets, the answer to the second half of that question is no, and that’s the point to invest.

— Ian Rickard

Recommended

• Which logo file formats work best for websites
• Website speed optimisation checklist: 2026 guide