JPG, PNG, WebP, AVIF or SVG? Our 2026 Decision Guide for Image Formats

On almost every site we audit, images are the heaviest thing on the page — usually 50 to 70 percent of total transfer. And in most of those audits, the problem is not that someone forgot to compress. It is that the wrong format was chosen at the start: a photograph exported as PNG, a logo shipped as a 900 KB JPG, a hero image served as the same file to a phone on 4G and a desktop on fibre.

The good news is that in 2026 the format decision is simpler than the number of options suggests. Browser support arguments that dominated this conversation five years ago are mostly settled — AVIF and WebP now work in every browser your analytics will realistically show you. What remains is a small set of trade-offs: lossy versus lossless, photo versus graphic, transparency or not, and how much encoding time you can afford.

This is the decision guide we actually use on client projects, with the numbers we see in practice. Your images will differ, but the ratios hold up remarkably well.

The thirty-second decision tree

If you only remember one section, make it this one. For each image, ask what it is, then pick accordingly.

• Logo, icon, chart, or illustration drawn from shapes and text: SVG, always, unless it came from a camera.
• Photograph on the web: AVIF first, WebP as fallback, JPG only if your pipeline cannot produce either.
• Screenshot or UI mockup with sharp text: lossless WebP, or PNG if the tooling insists.
• Image that needs transparency and is photographic: WebP or AVIF with alpha — not PNG.
• Image being sent to print, email attachments, or non-web software: JPG or PNG, because compatibility beats size there.

Everything below is the reasoning behind those five lines.

JPG: the format that refuses to die, for good reason

JPG is thirty-plus years old and still the most compatible raster format on Earth. Every camera, CMS, email client, printer driver and government upload portal accepts it. For a typical 1600 px wide photo at quality 80, expect roughly 200 to 300 KB — perfectly respectable.

Its weaknesses are known: no transparency, visible blocky artifacts on sharp edges and text, and it simply cannot match modern codecs at the same visual quality. The same 1600 px photo encoded as WebP lands around 25 to 35 percent smaller, and as AVIF around 45 to 55 percent smaller, at quality most people cannot tell apart in an A/B flip test.

Our position: JPG is no longer a delivery format for the web — it is a fallback and an interchange format. It is what you accept from clients and what you export when someone needs to open the file in unknown software. It should rarely be what your server actually sends to a modern browser.

PNG: massively overused, still occasionally right

PNG is lossless, supports full alpha transparency, and renders text and hard edges perfectly. That made it the default for two decades of screenshots, logos and anything transparent. It is also the single biggest source of wasted bandwidth we find in audits.

The failure mode is photographs. A photo that is 250 KB as a JPG is routinely 1.5 to 3 MB as a PNG, because lossless compression cannot do anything useful with photographic noise. We still see hero photos shipped as 4 MB PNGs in 2026, usually because a designer exported "highest quality" and nobody questioned it.

Where PNG still earns its place: pixel-perfect screenshots for documentation, images destined for further editing where generation loss matters, and any workflow where the receiving software predates WebP support. For pure web delivery, lossless WebP does everything PNG does at typically 20 to 30 percent smaller, so PNG is another format we keep at the edges of the pipeline rather than the middle.

WebP: the boring, correct default

WebP is the format we reach for when we do not want to think. It does lossy and lossless, supports transparency and animation, encodes fast, and has effectively 100 percent browser support. Lossy WebP beats JPG by a quarter to a third at equivalent quality; lossless WebP beats PNG by a fifth to a third. A photographic image with transparency — a product cutout, say — that would be 800 KB as a PNG is often 80 to 120 KB as a lossy WebP with alpha. That single swap has cut a client product-listing page from 9 MB to under 2 MB.

Its only real weakness is that AVIF beats it on compression. But WebP encodes in a fraction of the time, degrades more gracefully at low quality settings, and never surprises you. If your team ships one modern format and no fallback logic, ship WebP.

AVIF: the best compression, with two honest caveats

AVIF, built on the AV1 video codec, is the current efficiency champion. Photographs at 50 to 60 percent smaller than JPG are normal; on smooth, low-detail images we have seen 70 percent. It handles alpha, wide color gamut and HDR, and as of 2026 it works in every mainstream browser, including several Safari versions back.

Caveat one: encoding is slow — often 5 to 20 times slower than WebP at high effort settings. That is irrelevant if you encode once at build time or through an image CDN, and very relevant if you generate images on the fly. Caveat two: at aggressive quality settings AVIF tends to smooth away fine texture — skin, fabric, foliage — rather than showing blocky artifacts. The file looks clean at a glance but flat on inspection. For photography-led brands we encode AVIF at a higher quality setting than the size charts suggest, and it still wins.

Our recommendation: use the picture element with an AVIF source, a WebP source, and a JPG fallback. Every modern CMS and image CDN can automate this; there is no longer a good excuse for serving one-size-fits-all JPGs.

SVG: the category people forget is a category

SVG is not competing with the formats above — it is for a different kind of image entirely. Anything built from shapes, paths and text — logos, icons, charts, illustrations, diagrams — should be SVG. A logo that is 60 KB as a PNG is often 3 to 8 KB as an optimised SVG, and it stays razor sharp at every screen density and zoom level, forever. One file replaces the whole @2x/@3x export ritual.

Two rules we enforce. First, run every SVG through an optimiser: design tools export absurd amounts of editor metadata, and we routinely cut exported SVGs by 40 to 70 percent with zero visual change. Second, sanitise any SVG you did not create yourself before embedding it inline — SVG can carry scripts, and user-uploaded SVGs are a genuine XSS vector. Our free Gigai Tools platform has browser-based SVG optimisation and conversion tools for exactly this, and because everything runs client-side, the files never leave your machine.

What we actually set up for clients

The pipeline we deploy on nearly every project now looks the same, and it is worth stating plainly because the individual format debates matter less than having a pipeline at all.

• Masters are stored large and clean: original photos, editable SVGs, lossless screenshots.
• Delivery formats are generated automatically — AVIF plus WebP plus JPG fallback for photos, optimised SVG for graphics — never exported by hand.
• Responsive sizes via srcset, so a phone never downloads a 2400 px image; this saves more bytes than any codec choice.
• Lazy loading below the fold, and explicit width and height on every image to stop layout shift.
• A hard budget: if a page ships more than about 1 MB of images on first load, something gets renegotiated.

For one-off conversions — a client sends a 5 MB PNG that needs to become a lean WebP before a deadline — the image converters on Gigai Tools handle it in the browser in seconds, no upload, no signup.

The summary we give every client: SVG for anything drawn, AVIF-with-fallbacks for anything photographed, WebP when you want one simple answer, and JPG and PNG demoted to compatibility duty. Format choice is a five-minute decision that pays for itself on every single page view — get it right once, automate it, and stop thinking about it.