JPEG, PNG, WebP, AVIF and HEIC: which format when

Use AVIF for web photographs with a JPEG fallback, PNG for screenshots, logos and text, WebP if you want one modern format and no pipeline. Never use HEIC for anything leaving an Apple device: Chrome, Edge and Firefox do not decode it, and only Safari 17 and later displays it.

AVIF and HEIC are the same file format

This is not a simplification. Microsoft's Windows Imaging Component docs say it outright: "HEIF is a container, similar to TIFF, that can use different compression methods", where files "compressed with HEVC typically use the .heic file extension" and AV1 files "typically use the .avif file extension". AVIF v1.2.0, of 16 October 2025, builds on ISO/IEC 23008-12 plus ISO/IEC 14496-12, the ISO base media file format that .heic also sits on. The extension names the codec, not the container.

So HEIC is not an Apple format. It is ISO/IEC 23008-12, Edition 3 of July 2025, which defines brands for HEVC, AVC, JPEG, VVC and EVC. Apple picked the HEVC brand.

That explains the money. The free HEIF Image Extension is not enough alone: .heic, .hif and .heif also need the HEVC Video Extensions package, .avif the AV1 Video Extension. Microsoft's display catalog API in July 2026 lists the AV1 extension (9MVZQVXJBQ9V) at 0.00 USD and the only purchasable HEVC Video Extensions listing (9NMZLZ57R3T7) at 0.99 USD. Same container, different codec, different bill. Some PCs carry an OEM-supplied HEVC codec instead.

What each format can actually do

Two cells there contradict the usual comparison table. T.81 does define a lossless mode, in Annex H, at 2 to 16 bits per sample, but web tooling is built around the lossy DCT processes: treat JPEG as lossy, never as an archive. JPEG is also not RGB, since T.81 gives each component its own sampling factors, which is how 4:2:0 JPEGs exist.

JPEG having no alpha channel is the hardest constraint there. WebP carries 8-bit alpha in both modes, plus a hybrid of lossy RGB with lossless alpha that Google measures at 22% more bytes than a lossy quality-90 encode. AVIF stores alpha as a monochrome auxiliary image tagged urn:mpeg:mpegB:cicp:systems:auxiliary:alpha.

Browser support in 2026

AVIF landed in Chrome 85 on 25 August 2020, Safari on iOS 16.1 in October 2022, desktop Safari 16.4 in March 2023, Edge 121 on 25 January 2024. Firefox needs care: still-image AVIF shipped in Firefox 93 on 5 October 2021, animated AVIF in Firefox 113 on 9 May 2023, the version web-features counts. Edge 121 set the Baseline "newly available" date, and widely available follows 30 months later: the web-features explorer expects 25 July 2026, while the webstatus.dev API still reported "newly".

caniuse puts global support at 93.4%: roughly seven visitors in a hundred cannot decode AVIF, mostly on devices below iOS 16. The fallback is not optional.

WebP has been Baseline widely available since 16 March 2023, at 96.07% global support: Chrome 32, Edge 18, Firefox 65, Safari 14 and Safari on iOS 14. Desktop Safari adds a condition, per MDN: "You need Safari 14 or later as well as macOS Big Sur (11) or a more recent version."

HEIC is the outlier. MDN browser-compat-data for image/heif records chrome false and firefox false, Edge and Opera mirroring Chrome, safari 17, with Chrome's and Firefox's tracking bugs still open.

JPEG XL is back in Chromium and still not shipping. Chrome 145 decodes image/jxl through jxl-rs, a Rust decoder chosen over C++ libjxl "to meet Chromium's memory safety requirements", but only behind the #enable-jxl-image-format flag, and Chrome Platform Status still labelled it "Proposed" on 16 February 2026. Safari 17 has it on by default, Edge not at all: do not ship it in 2026.

Why HEIC creates friction the moment it leaves Apple

Apple introduced HEIF and HEVC in iOS 11 and macOS High Sierra 10.13. iPhone 7 and later, iPad (6th generation) and later and Apple Vision Pro capture them, and Apple calls that "recommended": JPEG is the opt-out. Android's format list gives HEIF a decoder from 8.0 and no encoder, so Android phones read your photos and never write them. The cause is patent licensing on the codec, not the container: Access Advance's HEVC Advance pool licenses patents essential to HEVC, and nothing like it attaches to AV1.

Two Apple settings cause the confusion, and people get the second backwards. To stop producing HEIC: Settings, Camera, Formats, Most Compatible, after which "All new photos and videos will now use JPEG or H.264 format." New only, so the existing library stays HEIC. On USB import, Apple says the media "might be converted to JPEG or H.264" unless Settings, Apps, Photos, Keep Originals is on. Switching Keep Originals on turns that helpful conversion off, the opposite of what a HEIC problem calls for.

Sharing is conditional. Over AirDrop, Messages and email the media "might automatically be shared in a more compatible format" if the receiver does not support HEIC. Might, not will. iCloud Photos does not convert at all: "the media is preserved in its original format, resolution, and frame rate." Upload forms fail predictably: image/heic is often missing from the accept list, and no browser but Safari renders it anyway.

One reason to keep HEIC inside Apple: on Windows, HEIF exposes two per-pixel planes nothing else offers: GUID_WICPixelFormat8bppDepth for distance from the viewer and GUID_WICPixelFormat8bppGain for the brightness gain that turns RGB into HDR. Microsoft notes that gain "is included only in HEIF files that were created by recent Apple iOS devices". Convert to JPEG and it is gone. On supported Macs, macOS Tahoe 26 saves HDR-format screenshots as HEIF too.

The 50% smaller claim needs an asterisk

AOMedia states that "AVIF can provide over 50% file size savings compared to JPEG and over 30% savings compared to WebP". Google puts WebP at "30% more compression than JPEG", lossless WebP at "26% smaller in size compared to PNGs", and 60% to 70% off a transparent PNG turned lossy with alpha.

Now the examples. web.dev repeats "greater than 50% savings vs. JPEG", then qualifies it: "exact savings will depend on the content, encoding settings, and quality target". Its demonstration file, 1120 by 840 pixels, is 18,769 bytes as AVIF against 20,036 as JPEG: 6%. Netflix's Kodak example is 20,429 bytes for JPEG 4:4:4 against 19,788 for AVIF 4:4:4, about 3%, and its point there is quality: "The AVIF encode is much better, with less blocking artifacts."

Can a WebP image grow larger than its source? Google's FAQ says yes, "usually when converting from a lossy format to WebP lossless or vice versa": a few-colour PNG pushed into lossy WebP, or a JPEG re-encoded as lossless WebP.

Encoding cost rarely appears. web.dev recommends encoder speed 6 and reports roughly 5x faster encoding with 8 threads. Jon Sneyers of Cloudinary timed single-threaded encodes of one large image in December 2022: mozjpeg at q75 took 0.9 seconds, libaom AVIF at speed 6 took 4.2 seconds. At typical quality settings, he found, "AVIF encoding is slower than most other codecs", and at web quality AVIF gains "about 15% over mozjpeg". He works on JPEG XL, so read it as partisan, but 15% and "over 50%" describe the same format.

Three WebP traps

Maximum pixel dimensions are 16383 by 16383, not the larger figure republished everywhere. Google's FAQ explains: "WebP is bitstream-compatible with VP8 and uses 14 bits for width and height." The RIFF container's 24-bit canvas fields reach 16,777,216 per side, which is where the wrong numbers come from. The bitstream wins; tall scans hit it first.

Lossy WebP is 8-bit Y'CbCr 4:2:0 and nothing else, a VP8 limit, which is why saturated red detail and coloured text over photographs smear. Lossless WebP is RGBA. AVIF does 4:4:4.

WebP does not load progressively. Google: "WebP does not offer a progressive or interlaced decoding refresh in the JPEG or PNG sense." It decodes incrementally instead. Animated WebP is 64% smaller than GIF when lossy and 19% when lossless, but costs 2.2x GIF's straight-line decode time, so long animations belong in a video file.

Recent changes that invalidate older advice

PNG Third Edition, a W3C Recommendation since 24 June 2025, standardised APNG animation (acTL, fcTL, fdAT), HDR through cICP with PQ and HLG, and EXIF through eXIf. "PNG cannot animate" and "PNG is SDR only" are both wrong now. Android 14 made AVIF encode and decode mandatory, so phones do produce AVIF.

The rules

• Web photographs: AVIF first, JPEG fallback, inside <picture>.
• One format only: WebP.
• Anything transparent: never JPEG.
• Screenshots, UI, logos, line art, text: PNG, or lossless WebP for 26% fewer bytes.
• Soft cut-out or shadow: lossy WebP with alpha, or AVIF.
• Masters and archives: lossless only, never a second JPEG generation.
• Over 16383 px on either side: not WebP.
• Fine red detail or coloured text on a photo: AVIF 4:4:4 or PNG.
• Photos to Windows or Android users, or an upload form: JPEG, or Most Compatible.
• Staying inside Apple: keep HEIC, and its depth and gain data.

Source order inside <picture> is load-bearing. MDN: "If the user agent does not support the given type, the <source> element is skipped." The browser takes the first match, so AVIF precedes WebP precedes JPEG. The <img> stays mandatory: MDN says it "provides a fallback" and describes the image's size, so it carries alt and sizing. CSS object-fit and object-position go on it, "not the <picture> element".