Posted · 9 min read
JPG vs PNG vs WebP vs AVIF: Picking the Right Image Format in 2026
A practical, no-nonsense guide to the four image formats that matter on the web in 2026. We compare compression models, file sizes, transparency, animation, browser support, and hardware decoding so you can pick the best image format for web delivery without guessing.
If you ship images on the web, the format you choose has more impact on page weight than almost any other single decision. A 4 MB hero image versus a 180 KB hero image is the difference between a site that feels instant and one that crawls on a mid-range Android phone over a flaky 4G connection. In 2026 we have four mainstream contenders worth caring about: the venerable JPG, the lossless PNG, the now-universal WebP, and the increasingly mature AVIF.
This guide walks through how each format actually works under the hood, where the byte savings come from, what tradeoffs you accept, and a clear recommendation for when to use which. By the end you should be able to answer the question "what is the best image format for web in 2026?" without hand-waving, and you should know exactly what to do when an artist hands you a 28 MB PNG screenshot at 5 PM on a Friday.
The cast of characters
JPG (sometimes spelled JPEG) was standardised in 1992 and is still the format most cameras shoot in. It uses a discrete cosine transform (DCT) on 8x8 blocks, quantises the frequency coefficients, and Huffman-codes the result. It is lossy by design and has no alpha channel, but it is fast, cheap to decode, and supported on literally every device built in the last thirty years.
PNG arrived in 1996 as a patent-free replacement for GIF. It uses DEFLATE (the same algorithm as zip and gzip) on top of optional row filters, so it is fully lossless. PNG supports a real 8-bit alpha channel, indexed palettes, and even 16-bit-per-channel colour. The price you pay is file size: photographic content compresses poorly with DEFLATE.
WebP was published by Google in 2010 and reached full cross-browser support around 2020. Lossy WebP uses VP8 intra-frame coding (the same prediction modes as the VP8 video codec) instead of plain DCT. Lossless WebP uses VP8L, a custom format with colour-cache and predictor-transform tricks. WebP supports alpha for both modes plus animation.
AVIF is the still-image profile of AV1, the video codec finalised in 2018 and shipped by virtually everyone by 2024. It uses much larger and smarter prediction blocks, more transform options, and a vastly better entropy coder than VP8. AVIF supports up to 12-bit colour, alpha, HDR, and animation.
How the compression actually works
JPG splits the image into 8x8 blocks, applies a DCT to each block, then divides the resulting coefficients by a quantisation matrix. High frequencies get crushed harder than low frequencies because the human eye is less sensitive to fine detail. Lower quality settings just multiply that quantisation matrix by a larger scalar. This is why JPG artefacts look like blocky ringing around hard edges: the encoder literally cannot afford to keep the high-frequency coefficients that describe the edge.
PNG does no perceptual compression at all. Each row of pixels gets a one-byte filter prefix (None, Sub, Up, Average, or Paeth) that predicts each pixel from its neighbours, and then DEFLATE compresses the residuals. If your image is a photograph, the residuals are still high-entropy noise and you save very little. If it is a screenshot full of repeated solid colours and crisp edges, the savings are enormous.
WebP lossy borrows VP8's spatial intra-prediction: each 4x4 or 16x16 block is predicted from already-decoded neighbouring pixels using one of ten prediction modes, and only the residual is transformed and quantised. Better prediction means smaller residuals, which means fewer bits. WebP lossless (VP8L) goes further with a custom colour cache, palette transforms, and a context-adaptive entropy coder.
AVIF essentially uses an entire modern video keyframe encoder. Block sizes go from 4x4 up to 128x128, transforms include DCT, ADST, and identity in multiple sizes, and there are 56+ intra-prediction modes including directional predictors at fine angular granularity. The CABAC-style arithmetic coder packs significantly more information per bit than JPG's Huffman tables. The result is roughly 50% smaller files than JPG at the same visual quality, at the cost of much heavier encoding.
File size at a glance
Same 4000x3000 photo (a daylight landscape, no transparency):
JPG (q=85) -> 1,180 KB
JPG (q=92) -> 1,940 KB
PNG (24-bit) -> 12,420 KB
WebP (q=85) -> 810 KB
WebP (lossless) -> 9,860 KB
AVIF (q=60) -> 495 KB
AVIF (q=80) -> 760 KB
Same 1920x1080 UI screenshot (flat colours, sharp text):
JPG (q=92) -> 410 KB (text fringes visibly)
PNG (8-bit indexed) -> 92 KB
PNG (24-bit) -> 280 KB
WebP (lossless) -> 74 KB
AVIF (lossless) -> 88 KBTwo takeaways from these numbers. First, on natural photographs AVIF is roughly 40 to 60 percent smaller than JPG and 30 to 40 percent smaller than WebP at matched perceived quality. Second, on synthetic content like screenshots and UI exports, lossless WebP usually wins outright, with PNG-8 a close second when the palette fits.
Browser support in 2026
JPG and PNG: 100 percent. There is nothing to discuss. They work everywhere a browser exists, including ten-year-old Android tablets and embedded WebViews you forgot about.
WebP: effectively 100 percent of browser traffic. Safari shipped support in iOS 14 and macOS Big Sur back in 2020, Chrome and Firefox have had it for much longer, and even most in-app browsers now decode it. As of 2026, serving WebP without a JPG fallback is no longer reckless for a typical consumer site.
AVIF: roughly 95 to 97 percent of browsers in 2026. Chrome, Edge, Firefox, Safari (16.4+), and the major Android WebViews all decode it. The remaining gap is mostly very old Android, some embedded WebViews on older smart TVs, and a long tail of corporate locked-down devices. For a public-facing site, AVIF with a WebP or JPG fallback is a safe default.
Transparency, animation, and colour depth
JPG has no alpha channel at all. If you need any kind of transparency, you cannot use it. This is the single most common reason designers reach for PNG when they should not.
PNG offers a true 8-bit alpha channel and supports up to 16 bits per colour channel, which makes it useful for high-precision intermediates in graphics pipelines. There is no animation in standard PNG; APNG exists but support is uneven outside of stickers and emoji.
WebP supports alpha in both lossy and lossless modes and has solid animation support that is significantly more efficient than animated GIF. Colour depth is 8 bits per channel, which is fine for almost all web content.
AVIF supports alpha, animation, 10- and 12-bit colour, wide gamuts, and HDR transfer functions. If you are publishing HDR photography or wide-gamut artwork, AVIF is currently the only mainstream web format that can carry the data faithfully.
Hardware decode and energy
JPG decoding is so cheap on modern hardware that it does not really matter; even a phone from 2015 decodes JPGs faster than the screen can display them. PNG decoding is heavier per pixel because DEFLATE is not parallel-friendly, but PNG payloads are typically smaller per image in screenshot-style use cases, so this is a wash in practice.
WebP lossy decoding uses the same VP8 silicon path that mobile chips have had for over a decade. Decode is fast and energy-efficient. WebP lossless decoding is software-only on most chips but still well within budget.
AVIF is where things get interesting. Software decode is genuinely heavier than JPG or WebP, occasionally by a factor of three to five on a single image. The good news is that most phones shipped after 2022 have AV1 hardware decode that the browser can route still images through; on those devices AVIF is actually as fast as JPG or faster. On older laptops without AV1 silicon, decoding a wall of AVIF thumbnails can show up in CPU profiles, so use it judiciously and lean on responsive image markup so the smallest variant is always the one decoded.
When to use each: the short version
- Use JPG for photographs when you need the absolute maximum compatibility and do not want to maintain multiple variants. Quality 82 to 88 is the usual sweet spot.
- Use PNG for screenshots, UI exports, logos with hard edges, and anything that needs lossless transparency in a pinch. Prefer 8-bit indexed PNG when the palette fits.
- Use WebP as the default web format in 2026. Lossy WebP for photos, lossless WebP for UI assets and icons that previously would have been PNG.
- Use AVIF when bandwidth and Core Web Vitals matter most, when you are serving HDR or wide-gamut content, or when you want the smallest possible LCP image. Always pair it with a WebP or JPG fallback through the picture element.
- Avoid GIF entirely. Animated WebP and AVIF are smaller and look better at the same byte budget.
A practical conversion workflow
Most teams do not need an elaborate build pipeline to take advantage of modern formats. The minimum viable workflow is simple: keep the original camera or design-tool export as your source of truth, then generate JPG, WebP, and AVIF variants at deploy time. For one-off conversions, a CLI does the job in seconds.
# Convert a single photo to all three modern variants
cwebp -q 85 hero.jpg -o hero.webp
avifenc --min 20 --max 30 -s 6 hero.jpg hero.avif
# Use the picture element so the browser picks the best one it understands
# <picture>
# <source srcset="hero.avif" type="image/avif">
# <source srcset="hero.webp" type="image/webp">
# <img src="hero.jpg" alt="..." width="1600" height="900">
# </picture>If you do not want to install command-line tools and you only have a handful of images, Multilities offers a browser-based image converter at /tools/image-convert that handles JPG, PNG, WebP, and AVIF in any direction without uploading your files anywhere; everything runs in your tab. For squeezing extra bytes out of an existing JPG or PNG without changing format, /tools/image-compress will re-encode at a quality you choose and show you the before-and-after byte counts.
WebP vs PNG: the question that will not die
The most common confusion in 2026 is still WebP vs PNG. The short answer: lossless WebP is strictly better than PNG for almost every web use case. It is smaller, it supports the same alpha channel, and every browser you care about decodes it. The only reasons to keep using PNG today are downstream tooling that does not accept WebP (some ad networks, some legacy CMS plugins, some print workflows) and the fact that PNG is the de facto interchange format among designers.
If you are building a new product from scratch, default your asset pipeline to lossless WebP for UI and lossy AVIF for photos, and only fall back to PNG and JPG when something refuses to accept the modern format.
Common gotchas
- Do not re-encode a JPG as another JPG at higher quality and expect the file to look better. The original quantisation already threw away information; you will only make the file larger.
- Do not save screenshots as JPG. The blocky ringing around text is unmistakable and unfixable. Use PNG or lossless WebP.
- Watch the colour profile. AVIF and modern WebP encoders preserve ICC profiles by default; older tools strip them and your image will shift hue on wide-gamut displays.
- Test your AVIF encoder's quality scale. Different encoders use different conventions: libavif uses a 0 to 100 quality, while avifenc historically used a quantiser min/max of 0 to 63 where lower is better.
- If you are using a CDN that re-encodes on the fly, make sure it is actually negotiating AVIF via the Accept header. Many CDNs default to WebP only unless you flip a setting.
What about JPEG XL?
JPEG XL is a genuinely good format, technically competitive with AVIF and with the unique trick of being able to losslessly transcode existing JPGs at roughly 20 percent smaller size. As of 2026 Safari ships it, Firefox supports it behind a flag, and Chrome still does not enable it by default. Until that changes, treat JXL as a format to watch rather than one to deploy. AVIF is the modern format with cross-browser support today.
The 30-second decision tree
If it is a photograph, generate AVIF and WebP, fall back to JPG. If it has transparency or sharp edges, generate lossless WebP, fall back to PNG. If you cannot run a build step, ship JPG for photos and PNG for everything else and move on with your life. Image formats are no longer a research project in 2026; the answers are mostly settled and the tooling is mature. Pick the right format, set up a fallback, and spend the time you saved on something else.