Choosing an Image Format in 2026: JPEG vs PNG vs WebP vs AVIF vs HEIC — A Practitioner's Guide

Choosing an Image Format in 2026: JPEG vs PNG vs WebP vs AVIF vs HEIC — A Practitioner's Guide

Every image on the web is a compromise between three things: file size, visual quality, and whether the thing actually renders where you send it. The formats have changed, the browsers have changed, and most advice online is stuck in 2021 — still hedging about WebP support, still treating AVIF as experimental, still not mentioning that the photos on half your users' phones are in a format no browser can display.

Here's the 2026 state of play, with real numbers, and a decision tree for the situations that actually come up.

The mental model: four questions decide the format

Before comparing formats, know what you're optimizing. Every image decision reduces to:

1. Is it photographic or synthetic? Photos (continuous tones, noise) want lossy compression. UI screenshots, logos, diagrams (flat colors, hard edges) want lossless — lossy compression smears their sharp edges into visible artifacts.
2. Does it need transparency? JPEG has no alpha channel, full stop. PNG, WebP, and AVIF do.
3. Where will it render? A modern browser accepts anything. Email clients, social media crawlers, and native apps are years behind.
4. Is it actually a raster at all? Logos, icons, and diagrams are usually vector art that someone exported to pixels. SVG scales to any size and often weighs less than a favicon.

Answer those four and the format picks itself. Now, the contenders.

JPEG — the universal fallback

Born 1992, and still the only photographic format that renders everywhere: every browser ever shipped, every email client, every social crawler, every embedded webview in every app.

• Compression: lossy DCT. Decent, but every newer format beats it.
• Transparency: none. Converting a transparent PNG to JPEG flattens the alpha onto a background color — which is why our PNG to JPG converter makes you choose one.
• The 2026 role: the last <source> in your fallback chain, HTML email, and og:image. On your own site, serving plain JPEG to browsers leaves 30-60% of your bandwidth on the table.

If you must ship JPEG, at least ship it well: quality 75-85, progressive encoding, and run it through a JPEG compressor — camera-original JPEGs are typically 3-5x larger than they need to be for web display.

PNG — lossless, transparent, and misused

PNG stores pixels exactly, compressed with DEFLATE. That makes it correct for flat-color graphics and catastrophic for photos.

• Great at: UI screenshots, charts, pixel art, anything with sharp text — pixel-perfect and reasonably small.
• Terrible at: photographs. Photographic noise doesn't compress losslessly; a photo saved as PNG routinely comes out 5-10x larger than a visually identical lossy version.
• The classic mistake: design tools exporting photos as PNG "to be safe." Check your homepage — if the hero image is a 2.4MB PNG of a photo, that's your Largest Contentful Paint problem right there.
• The 2026 role: compatibility contexts (email, og:image, favicons) and as the lossless master you keep on disk. For serving to browsers, lossless WebP does the same job ~25% smaller — PNG to WebP is a free win with zero quality loss.

If a PNG has to stay a PNG, compress it — palette reduction alone often halves UI screenshots with no visible change.

WebP — the safe modern default

Google's 2010 format finally became universal when Safari 14 shipped support in September 2020. In 2026 it renders in effectively every browser your analytics will ever show you.

• Compression: ~25-34% smaller than JPEG at equivalent visual quality (Google's own study; our experience matches). Has both lossy and lossless modes, alpha in both, plus animation.
• One format, all jobs: lossy WebP replaces JPEG, lossless WebP replaces PNG, animated WebP replaces GIF. That simplicity is underrated in a build pipeline.
• Weaknesses: no HDR, no wide gamut, capped at 8-bit color. And AVIF now beats it on pure compression.
• The 2026 role: the fallback between AVIF and JPEG, or the primary format if your pipeline can't afford AVIF's encode times.

Converting is trivial: JPG to WebP, PNG to WebP, and if you already have WebP files that came out too large, the WebP compressor re-encodes at a quality level you pick.

AVIF — the best compression you can actually ship

AVIF is a still-image derived from the AV1 video codec. The last browser holdout fell in January 2024 when Edge shipped support (Chrome had it since 2020, Firefox since 2021, Safari since 16.4 in 2023). Two-plus years later, hedging about AVIF support is officially outdated advice.

• Compression: typically ~50% smaller than JPEG and 15-30% smaller than WebP at equivalent visual quality. On low-quality settings it degrades gracefully (smooth, not blocky) — a big deal for aggressive optimization.
• Beyond compression: 10/12-bit color, HDR, wide gamut, alpha, animation. It's the only broadly-supported web format that can represent what modern phone cameras actually capture.
• The costs: encoding is slow — several times slower than WebP even with fast encoders, which matters if you resize images on the fly rather than ahead of time. Decode is fine. And on razor-sharp synthetic graphics, lossless WebP sometimes wins.
• The 2026 role: first choice for every photographic image on the web, served via <picture> with a fallback.

Start with JPG to AVIF, PNG to AVIF, or upgrade existing WebP with WebP to AVIF. Need to go the other way for a stubborn tool that won't accept AVIF? AVIF to JPG.

HEIC — the format on your phone that the web can't read

HEIC is what iPhones have shot by default since iOS 11 (2017): a HEIF container holding HEVC-compressed images. It's genuinely good — roughly half the size of an equivalent JPEG, 10-bit color, and multi-image containers for bursts and Live Photos.

It is also, for web purposes, a dead end:

• No browser renders it except Safari 17+ on Apple hardware. Chrome, Firefox, and Edge show nothing.
• Windows can't open it without a paid HEVC codec extension from the Microsoft Store.
• The reason is patents: HEVC decoding requires licensing fees browser vendors won't pay, and that isn't changing.

So HEIC is a capture format, not a delivery format. When a client emails you IMG_4032.HEIC and your CMS rejects it, convert it — our HEIC to JPG converter decodes it entirely in your browser via WebAssembly, so the photos never touch a server. If it keeps happening, the sender can switch their iPhone to JPEG capture: Settings > Camera > Formats > Most Compatible.

The rest of the field, quickly

• GIF — 256 colors, enormous files. In 2026 it survives purely as a word. Animated WebP/AVIF are ~10x smaller; for anything longer than 2 seconds, use an actual <video> element.
• SVG — not a competitor but a category: vector art. Logos, icons, and diagrams as SVG are resolution-independent and often smaller than any raster. Run exports through the SVG optimizer (design tools emit shocking amounts of cruft), and sanitize any SVG you accept from users — it's XML and can carry scripts.
• JPEG XL — technically superb (including lossless recompression of existing JPEGs at ~20% smaller), but only Safari ships it. Chrome removed its experimental support in 2023, and despite renewed interest around a Rust decoder, neither Chrome nor Firefox enables it by default as of mid-2026. Not shippable to the open web without fallbacks that erase its benefit. Revisit in a year.

The numbers, side by side

Typical results for a photographic image at equivalent visual quality (your content will vary — measure, don't assume):

For flat-color graphics, invert your instincts: PNG and lossless WebP are small and perfect; lossy JPEG/AVIF at web quality produce visible edge artifacts.

The decision tree

• Photo on your website → AVIF, WebP fallback, JPEG last resort (code below)
• UI screenshot / chart / pixel-precise graphic → lossless WebP (PNG if a tool demands it)
• Logo, icon, diagram → SVG, optimized
• Photo with transparent background → AVIF or WebP with alpha (never JPEG — no alpha; PNG only under duress — huge)
• HTML email → JPEG for photos, PNG for graphics. Nothing newer; desktop Outlook renders with Word's engine and shows broken icons for WebP/AVIF/SVG
• og:image / social cards → 1200×630 JPEG or PNG. Platform crawlers (WhatsApp especially) still choke on modern formats
• Favicon → SVG + PNG fallbacks (our favicon generator emits the full set)
• HEIC from an iPhone → convert to JPEG for sharing, or AVIF for web serving
• Animation → <video> for anything substantial; animated WebP for tiny loops; GIF never

Serving it: the picture element

The whole strategy in one block of HTML — browsers pick the first source they support, top to bottom:

<picture>
  <source srcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w" type="image/avif" />
  <source srcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w" type="image/webp" />
  <img
    src="/img/hero-800.jpg"
    srcset="/img/hero-800.jpg 800w, /img/hero-1600.jpg 1600w"
    sizes="(max-width: 800px) 100vw, 800px"
    width="800" height="450"
    alt="Describe the image"
    fetchpriority="high"
  />
</picture>

Notes that save debugging time:

• width and height are not optional. They let the browser reserve space before the image loads, which is the difference between CLS 0 and a layout-shift penalty.
• fetchpriority="high" on the LCP image only (usually the hero). loading="lazy" on everything below the fold — but never on the LCP image, which is the single most common self-inflicted LCP regression.
• Resize before you convert. Serving a 4000px image into an 800px slot wastes more bytes than any format decision recovers. Generate 2-3 widths per image (image resizer) and let srcset pick.
• Or skip all of this with a CDN. Cloudflare, Fastly, and the image CDNs can negotiate format from the Accept request header and serve AVIF/WebP from a single JPEG URL. Same result, less markup — just verify with DevTools that it's actually happening.

Two pipeline rules that outlast any format war: keep your originals as masters (every conversion derives from the master, never from another conversion — generational loss stacks), and strip metadata before publishing — camera JPEGs and HEICs carry EXIF data including GPS coordinates (check what's in yours).

Why this is a Core Web Vitals story

On most pages, the Largest Contentful Paint element is an image, and images are 40-60% of transferred bytes. Moving photos from JPEG/PNG to AVIF with proper sizing typically cuts image weight by half or more, which shows up directly in LCP — and LCP is the Core Web Vital that correlates with ranking and bounce rate. If you're chasing a "Needs improvement" flag in Search Console, the image audit in the how-to above is usually the highest-leverage hour you can spend. (Our Core Web Vitals optimization guide covers the rest of the checklist.)

The one-paragraph version

Serve AVIF with a WebP or JPEG fallback for photos; SVG for anything that's really vector art; lossless WebP (or PNG where compatibility demands) for screenshots and UI graphics. Keep JPEG/PNG for email and og:images, convert HEIC on sight, and spend your remaining effort on sizing, width/height attributes, and lazy-loading — the boring details that move Core Web Vitals more than the format logo wars do.