Web Image Formats: Which One Should You Choose for a Fast Website?

In brief

‍

WebP and AVIF deliver 25-50% smaller file sizes than JPEG at equivalent visual quality. For photos and complex images, use WebP as your baseline (90%+ browser support) with AVIF as a progressive enhancement. PNG remains essential for graphics requiring transparency, while GIF should be replaced by modern formats in nearly all cases.

• WebP reduces photo file sizes by 25-35% vs JPEG without visible quality loss
• AVIF offers even better compression but Safari only gained full support in 2023
• PNG is still required for transparency, but modern platforms serve WebP with alpha channel
• Format choice impacts Core Web Vitals — LCP improvements of 0.5-1.5s are common

You've probably heard that images slow down websites. You may have run a PageSpeed Insights test and seen the recommendation to "serve images in next-gen formats". But when you look at your image library — hundreds of JPEGs, a handful of PNGs, maybe a GIF or two — the advice feels abstract. Which format actually makes a difference? And more importantly, which one do you use where?

‍

The answer isn't "convert everything to WebP and call it a day". Different images serve different purposes. A product photo with a transparent background has different needs than a hero image, which has different needs than a logo. The format that works for one will bloat the file size or break the rendering for another.

‍

This article walks through the five formats that matter in 2026 — WebP, AVIF, JPEG, PNG, and GIF — and gives you a decision framework based on where the image lives on your site and what it needs to do. Every recommendation comes with a use case and a free tool you can open in your browser.

‍

Why do your images slow down your site more than you think?

‍

Images remain the heaviest resource type on a home page: around 1,054 KB on the median desktop page, for a median total page weight of 2,652 KB, or roughly 40% according to the 2024 Web Almanac (HTTP Archive). A single uncompressed JPEG hero image can weigh 2-3 MB. On a 4G connection, that alone can take 1.5-2 seconds to load. Google measures Largest Contentful Paint (LCP) — the time it takes for the biggest visible element to render — as a Core Web Vitals metric. If that element is a heavy image, you're starting in the red before the rest of the page even loads.

‍

The problem isn't just size. It's also format inefficiency. JPEG was designed in 1992. It does a decent job compressing photographic images, but it leaves a lot of data on the table compared to modern codecs. A 500 KB JPEG typically drops to around 330-375 KB as WebP with no visible quality difference. Those saved kilobytes can be the difference between an LCP of 2.8 seconds ("needs improvement") and 1.8 seconds, under the 2.5-second threshold Google considers good.

‍

Most site owners upload images straight from their camera or designer without a second thought. Platforms like Webflow and Shopify handle some optimization automatically, but they can't make up for a fundamentally inefficient source file. If you're uploading a 5 MB PNG when a 200 KB WebP would do the same job, no CDN is saving you.

‍

AVIF, WebP, JPEG, PNG, GIF — what's the real difference that matters?

‍

JPEG is the baseline. It's been the web standard for photos since the 1990s. It compresses well, it's universally supported, and it degrades gracefully — meaning you can crank up the compression until you see artifacts, then back off. The weakness: it doesn't support transparency, and the compression algorithm is outdated compared to newer formats.

‍

PNG was designed for lossless compression and transparency. It's the go-to for logos, icons, screenshots, and any graphic with sharp edges or text. The tradeoff: file sizes are significantly larger than JPEG for photographic content. A 200 KB JPEG can easily become a 1.2 MB PNG if you convert it without changing the content type.

‍

WebP is Google's answer to JPEG and PNG. According to Google's documentation, it compresses photos 25-34% smaller than JPEG at equivalent quality (SSIM index), and it supports transparency like PNG. Today, WebP is supported by more than 96% of browsers in use worldwide, according to Can I use. The only holdout was Safari, which added full support in macOS Big Sur and iOS 14. For most use cases, WebP is now the practical default.

‍

AVIF is the newest format in the comparison. It's based on the AV1 video codec and produces substantially lighter files: after rolling out AVIF, the CDN Imgix reported roughly 35% byte savings versus WebP and 60% versus JPEG, figures relayed by web.dev. The catch: browser support was inconsistent until Safari added full support in late 2023. As of 2026, AVIF is safe to use with a WebP fallback, but it's not yet the primary format for most platforms. Shopify doesn't auto-generate AVIF variants. Webflow's hosting pipeline does, automatically, for the images you upload.

‍

GIF is functionally obsolete for most web use. It was designed for simple animations and low-color graphics, but modern video formats (MP4, WebM) compress animated content far more efficiently: in web.dev's example, a 3.7 MB GIF drops to 551 KB as MP4 and 341 KB as WebM, 85 to 91% less. If you're using GIF for anything other than a tiny icon or a meme, you're leaving massive performance gains on the table. Replace animated GIFs with short looping MP4s and static GIFs with PNG or WebP.

‍

Which format should you choose based on where it lives on your site?

‍

Hero images and large photos: WebP, with AVIF as a progressive enhancement if your platform supports it. These are the images that dominate your LCP score. A 1920x1080 hero image in JPEG might weigh 800 KB. The same image in WebP will weigh 250-300 KB. That's a 0.8-1.2 second improvement in load time on a typical mobile connection. If you're on Webflow or Shopify, upload a high-quality JPEG and let the platform generate WebP variants automatically. If you're on WordPress, use a plugin like ShortPixel or Imagify to handle the conversion and fallback logic.

‍

Product photos with transparency: WebP with alpha channel. PNG used to be the only option here, but WebP now handles transparency just as well and compresses 26% smaller in lossless mode, and up to three times smaller in lossy mode. Shopify and most modern e-commerce platforms serve WebP by default for product images. If you're manually exporting from Photoshop or Figma, export as PNG first, then run it through a converter like Squoosh to generate a WebP version. Keep the PNG as a fallback for older browsers, but serve the WebP to everyone else.

‍

Logos and icons: SVG if the graphic is vector-based, PNG if it's rasterized. SVG (Scalable Vector Graphics) is a text-based format that scales infinitely without quality loss and typically weighs under 5 KB. It's ideal for logos, icons, and simple illustrations. If your logo was designed in Illustrator or Figma, export it as SVG. If it's a raster image (photographed or heavily textured), use PNG. WebP works for logos too, but the file size difference is negligible at small dimensions, and PNG has better tooling support for designers.

‍

Screenshots and UI mockups: PNG for sharpness, WebP if file size is a concern. Screenshots contain a lot of text and sharp edges, which PNG handles better than JPEG. But a full-screen screenshot can still weigh 600-800 KB as PNG. Running it through a WebP converter will cut that to 200-300 KB without blurring the text. If you're embedding a lot of screenshots (documentation, case studies, tutorials), WebP is worth the conversion effort.

‍

Background images and textures: WebP or AVIF, heavily compressed. Background images are often decorative and don't need the same quality threshold as foreground content. You can push WebP compression to 70-80% quality (vs the typical 85-90% for photos) and most users won't notice the difference. If the background image is purely aesthetic (subtle gradient, light texture), consider replacing it with CSS gradients or SVG patterns instead — zero HTTP requests, zero file size.

‍

Should you always compress an image before uploading it?

‍

Yes, but the type of compression matters. There are two kinds: lossy and lossless. Lossy compression (JPEG, WebP, AVIF) discards data to reduce file size. You control how much data is discarded via the quality slider. Lossless compression (PNG, GIF) rearranges data without throwing anything away. The file gets smaller, but the image is pixel-identical to the original.

‍

For photos, use lossy compression. A JPEG or WebP at 85% quality is visually indistinguishable from 100% quality but weighs 40-50% less, according to Addy Osmani's measurements in Essential Image Optimization. Photographers and designers often export at 100% quality by default, which is overkill for web use. The human eye can't perceive the difference on a screen, especially on mobile. Most modern platforms (Webflow, Shopify, Squarespace) apply lossy compression automatically when you upload, but if you're uploading a 5 MB source file, the platform has to work harder and the result is still larger than if you'd pre-compressed it.

‍

For graphics with text or sharp edges, use lossless compression. PNG supports lossless compression: ImageOptim relies by default on lossless optimizers, whereas TinyPNG uses lossy compression ("quantization" merges similar colors) for an average 75% reduction in file size — the pixels really are modified. This is especially important for screenshots, logos, and diagrams where any quality loss makes text harder to read.

‍

One common mistake: compressing an image multiple times. If you export a JPEG at 80% quality, then upload it to a platform that compresses it again to 75%, you're compounding the quality loss. The second compression pass amplifies the artifacts from the first. Always compress once, from the highest-quality source you have, and avoid re-compressing already-compressed images.

‍

What free tools let you optimize images without Photoshop?

‍

Squoosh is Google's open-source image compressor. It runs entirely in your browser, so your images never leave your machine. You drag an image in, choose a format (WebP, AVIF, JPEG, PNG), adjust the quality slider, and compare the before/after side by side. It's the fastest way to test different compression settings and see exactly what you're trading off. The only limitation: it's one image at a time. If you need to process 50 product photos, you'll want a batch tool.

‍

ImageOptim (Mac only) is a drag-and-drop app that handles lossless compression for PNG, JPEG, and GIF. It's fast, it's local, and it integrates with macOS's right-click menu. You can drop an entire folder of images and it'll compress them all without changing the file format. It won't convert JPEG to WebP — it just makes your existing files smaller.

‍

XnConvert (Windows, Mac, Linux) is a batch image processor that handles format conversion, resizing, and compression. It's more complex than Squoosh or ImageOptim, but it's the best free option if you need to convert 200 images from PNG to WebP in one pass. The UI is dated but functional. You set up a processing pipeline once (input format, output format, quality settings), then drop folders of images through it.

‍

TinyPNG (web-based) compresses PNG and JPEG files using lossy techniques that preserve perceived quality. You upload up to 20 images at a time (5 MB each), and it returns compressed versions. It's convenient for small batches, but the 20-image limit makes it impractical for large projects. The compression is good — a substantial file size reduction with minimal visible quality loss — but you're uploading files to a third-party server, which may not be acceptable if you're working with client assets or proprietary content.

‍

If you're on WordPress, plugins like ShortPixel, Imagify, or Smush handle compression and format conversion automatically on upload. They'll generate WebP variants, serve them to modern browsers, and fall back to JPEG/PNG for older ones. The free tiers are usually capped at 100-500 images per month (100 free credits per month with ShortPixel, 500 free compressions per month with TinyPNG), but the paid tiers are under $10/month for most small business use cases.

‍

How do Webflow and Shopify handle image formats automatically?

‍

Webflow auto-generates WebP and AVIF variants for every image you upload. When a visitor loads your site, Webflow's CDN detects their browser and serves the most efficient format it supports. Modern browsers (Chrome, Edge, Firefox, Safari 14+) get WebP. Browsers that support AVIF (Chrome 90+, Firefox 93+, Safari 16+) get AVIF. Older browsers get the original JPEG or PNG. You don't configure this — it happens automatically as part of Webflow's hosting pipeline.

‍

Webflow also generates responsive variants at multiple sizes (typically 500px, 800px, 1080px, 1600px, and 2000px wide) and uses the srcset attribute to serve the right size based on the visitor's screen resolution. This means a mobile visitor on a 375px-wide screen gets a 500px image, not the full 2000px version. Combined with format optimization, this can reduce image payload by 70-90% on the smallest screens, according to the cases documented by CSS-Tricks.

‍

Shopify generates WebP variants automatically for product images, collections, and any image uploaded through the admin. At the time of writing, in early 2026, Shopify did not generate AVIF variants: it defaulted to WebP for modern browsers and JPEG as a fallback. This is a deliberate choice: WebP has near-universal support and AVIF's incremental compression gains don't justify the additional CDN processing cost at Shopify's scale. For most stores, this is fine. The performance difference between WebP and AVIF is closer to 25-30% in file weight — a test at equal visual quality (DSSIM) measures a median reduction of 31.5% for WebP versus 50.3% for AVIF against the same reference JPEGs — which often matters less than other optimization levers (lazy loading, image dimensions, CDN latency).

‍

Shopify also auto-crops and resizes images based on theme settings. If your product image is 3000x3000 pixels but the theme displays it at 600x600, Shopify serves a 600px variant. This works well for standard use cases but can cause issues if you're doing custom front-end work and need precise control over image dimensions. In those cases, you'll want to upload pre-sized images or use Shopify's image transform URLs to request specific sizes on the fly.

‍

Both platforms strip EXIF metadata (camera info, GPS coordinates, timestamps) from uploaded images. This is good for privacy and file size — EXIF data adds weight to the file with no visual benefit on display — but it means you lose that data if you need it later. If you're a photographer or you need to preserve metadata for licensing reasons, keep the original high-res files archived off-platform.

‍

When does image optimization stop being enough — what comes next?

‍

Image format and compression are foundational, but they're not the only levers. Once you've converted to WebP, compressed to 80-85% quality, and confirmed your platform is serving responsive variants, the next bottleneck is usually lazy loading. Lazy loading defers the download of below-the-fold images until the user scrolls near them. On long pages with lots of images, web.dev's tests show that lazy loading cuts 50 to 70% of the image bytes loaded up front. Webflow and Shopify enable lazy loading by default for most images, but if you're on a custom platform, you'll need to implement it yourself using the loading="lazy" attribute or a JavaScript library like lazysizes.

‍

The next level is a CDN with adaptive image optimization. Services like Cloudflare Images, Imgix, or Cloudinary sit between your site and the visitor and make real-time decisions about format, size, and compression based on device type, browser, and network conditions. A visitor on a slow 3G connection gets a more aggressively compressed image than someone on gigabit fiber. This is overkill for most small sites, but if you're serving millions of images per month or you have a global audience on widely varying connection speeds, it's the most effective way to squeeze out the last 10-20% of performance.

‍

Beyond images, the next bottleneck is usually JavaScript. A site can have perfectly optimized images and still feel slow if 500 KB of JavaScript blocks the main thread for 2-3 seconds. Image optimization gets you most of the way to a good LCP score, but to hit Interaction to Next Paint (INP) and Total Blocking Time (TBT) thresholds, you'll need to audit your scripts. That's a different audit, but the principle holds: measure first, then fix what costs you the most.

‍

One more thing: don't optimize prematurely. If your site has 10 pages and 50 images, manually converting them to WebP in Squoosh is fine. If you have 500 pages and 2,000 images, you need a systematic approach — either a platform that handles it automatically (Webflow, Shopify) or a build pipeline that converts images as part of deployment. The goal is to make optimization automatic so it scales with your content. One-off optimizations don't stick.