Three formats cover almost every photo on the web today. JPG has been the default for three decades. WebP arrived in 2010 and is now displayed by every current browser. AVIF is the newest of the three, built on a video codec, and it usually makes the smallest files. A performance audit will tell you to "serve images in modern formats", and then an upload form or an email client will refuse the modern file you made.
Choosing between them is less about which format is best and more about where the image is going. A hero image on a landing page, a product photo in a marketplace listing, and a picture attached to an email have different answers. This guide compares the three on the attributes that decide it: file size, quality, transparency, color depth, animation, encoding cost and support outside the browser. Then it gives a decision table and shows how to convert between them.
TL;DR: For images on a website, serve AVIF first with WebP as the fallback and JPG as the last resort, using the
<picture>element or server negotiation; AVIF is usually smallest, WebP is close behind and faster to encode, and JPG opens everywhere. For images that leave the browser (email, uploads, print, office software), use JPG, or PNG when transparency matters. To make files other programs accept, the AVIF to JPG converter and WebP to JPG run client-side, nothing uploaded, free, no signup; JPG to WebP and PNG to WebP go the other way.
What are AVIF, WebP and JPG?
All three are raster image formats for photographs, and they differ mainly in the age and design of their compression.
JPG (JPEG) is the still-image method standardized in ITU-T Recommendation T.81 in 1992. It divides the picture into 8x8 pixel blocks, transforms each with a discrete cosine transform, and discards the high-frequency detail the eye notices least. Files are usually wrapped in the JFIF container from ITU-T T.871.
WebP is Google's format, now specified in RFC 9649. Its lossy mode uses the keyframe coding of the VP8 video codec, and it has a separate lossless mode, plus transparency and animation. The guide on what WebP is and why saved images come out as .webp covers it in depth.
AVIF is the AV1 Image File Format, published by the Alliance for Open Media as the AVIF specification. It stores images coded with the AV1 video codec inside a HEIF container, the same box structure iPhone HEIC photos use. AV1 is offered under a royalty-free patent license from the Alliance for Open Media, which is one reason browsers adopted AVIF faster than HEIC.
AVIF vs WebP vs JPG: the comparison table
AVIF leads on compression and capability, JPG leads on compatibility and encoding speed, and WebP sits between them on nearly every row.
| Attribute | AVIF | WebP | JPG |
|---|---|---|---|
| Specification | AOMedia AVIF, AV1 codec | IETF RFC 9649 | ITU-T T.81 and T.871 |
| Introduced | 2019 | 2010 | 1992 |
| Compression | Lossy or lossless | Lossy or lossless | Lossy |
| Typical photo size | Smallest | Small | Largest of the three |
| Bit depth | 8, 10 or 12 bits per channel | 8 bits per channel | 8 bits per channel in practice |
| HDR and wide color | Yes | No | No |
| Transparency | Full alpha | Full alpha | None |
| Animation | Image sequences | Yes | No |
| Encoding speed | Slow, CPU-heavy at high effort | Moderate | Fast |
| Browser display | Chrome 85, Firefox 93, Safari 16, Edge 121 and later | All current browsers | Universal |
| Desktop apps, email, upload forms | Weakest | Patchy | Universal |
| Best use | Largest web images where bytes matter most | General web images, broad fallback | Anything that leaves the browser |
The row that surprises people is encoding speed. AVIF's small files come from an encoder that searches hard for the best way to code each block, and that search takes time. A build step that converts thousands of product images to WebP in minutes can take much longer for AVIF at a high effort setting. For a site that encodes once and serves millions of times, the trade is usually worth it. For images generated on the fly per request, it may not be.
Which format makes the smallest files?
AVIF usually makes the smallest files at similar visual quality, WebP is next, and JPG is the largest. The size of the gap depends heavily on the image and the encoder settings.
For WebP there is a published reference point: Google's WebP overview reports lossy WebP files 25 to 34% smaller than comparable JPEG at equivalent SSIM quality, and lossless WebP 26% smaller than PNG. AVIF commonly improves on WebP again for photographs, with the largest gains on smooth gradients, skies and skin, where JPEG's 8x8 blocks show first.
Three cautions keep those numbers honest.
- Quality numbers do not match across formats. A JPG at quality 80, a WebP at 80 and an AVIF at 80 are not the same visual quality, and different encoders for the same format disagree too. Compare files by looking at them, or by a metric such as SSIM, never by the slider value.
- Low-detail images save less. A flat illustration or an already heavily compressed JPEG has little left to squeeze.
- Re-encoding a lossy file stacks losses. Converting a JPG to AVIF or WebP starts from a picture that already lost detail. Encode from the original camera file, PNG or high-quality master whenever you can.
How much does the format choice matter for page weight?
It matters most on image-heavy pages, because images are usually the largest share of what a visitor downloads. The arithmetic is straightforward. A catalog page with 40 product photos at around 400 KB each carries 16 MB of images as JPG. At the 25 to 34% saving Google reports for WebP, the same set lands somewhere between about 10.5 and 12 MB. AVIF typically trims further on top of that.
On a fast desktop connection the difference is modest. On a phone over a slow mobile network, several megabytes is the gap between a page that settles quickly and one that visitors abandon, and images near the top of the page feed directly into how fast the largest visible element renders.
Format is not the only lever, and often not the biggest one. Sending a 4000 px wide photo to a 400 px slot wastes far more bytes than choosing WebP over AVIF. Resize to the displayed size first, provide srcset variants for different screens, lazy-load images below the fold, and then pick the format. Doing it in the other order optimizes the wrong thing.
How do they differ in quality and artifacts?
Each format fails in its own way when pushed to small sizes, and knowing the failure helps you pick.
JPG breaks into visible 8x8 blocks and "ringing", faint ripples around sharp edges such as text on a photo. WebP's lossy mode softens detail and, because it stores color at half resolution, can leave colored fringes around thin red or blue lines. AVIF tends to blur fine texture rather than block, so a heavily compressed AVIF looks smooth and slightly waxy, which is less objectionable in photos and more noticeable in fabric, hair and foliage.
For graphics with hard edges, flat color and text, none of the lossy modes is ideal. PNG or lossless WebP keeps edges exact.
Loading behavior differs too. T.81 defines a progressive mode for JPEG, in which a blurry version of the whole image appears first and sharpens as more data arrives, so a large progressive JPG feels fast on a slow connection even before it finishes. WebP and AVIF as commonly served draw only once enough of the file has arrived, which their smaller size usually makes up for. On very large hero images over poor connections, that difference can be visible, and it is one more reason to resize before choosing a format.
Where do PNG and GIF fit?
Neither is a photo format, and neither competes directly with the three above. PNG, defined in the W3C PNG specification, is lossless: the right choice for screenshots, diagrams, logos and editing masters, and the wrong one for photographs, which it stores at several times the size of a JPG. GIF is limited to 256 colors per frame and survives mainly for short animations in places that will not play anything newer.
On a website, both are usually better served as WebP or AVIF: lossless or high-quality lossy for PNG-style graphics, animated WebP for GIF-style clips. Outside the browser, PNG remains the safe format for anything with transparency, since JPG cannot hold it.
Which format supports transparency, HDR and animation?
AVIF supports all three, WebP supports transparency and animation but not HDR, and JPG supports none of them.
Transparency. AVIF stores alpha as an auxiliary image, and WebP has an alpha channel in both lossy and lossless modes. Either can hold a product cutout with a soft edge at a fraction of a PNG's size. JPG has no transparency, so any transparent area must be filled with a solid color when converting to it.
HDR and wide color. AVIF can use 10 or 12 bits per channel, which is what HDR photos from recent phones and cameras need to avoid banding in bright skies. WebP and JPG are 8-bit.
Animation. WebP animations are widely used as a smaller replacement for GIF. AVIF defines image sequences, though support for animated AVIF in software outside browsers is thinner.
Where does each format still fail?
Support inside current browsers is solved for all three. Support everywhere else is where the choice bites.
AVIF displays in Chrome from version 85, Firefox from 93, Safari from 16, and Edge from 121. Older browsers, older operating system photo viewers, many office suites, and a long list of upload forms do not accept it. Saving an AVIF from a web page and dropping it into a presentation is the classic failure.
WebP is further along. Every current browser displays it and most modern operating systems open it, but some email clients, print services and older desktop software still refuse it.
JPG opens on essentially every device, application and form. That is why it remains the right format for any image whose destination you do not control.
Which format should you use? A decision table
Decide by destination first, then by content.
| Situation | Use | Why |
|---|---|---|
| Hero and product images on your own site | AVIF, with WebP and JPG fallbacks | Smallest bytes on the heaviest images |
| General site images, simple pipeline | WebP, with JPG fallback | Near-universal browser support, fast to encode |
| Images generated per request | WebP or JPG | AVIF encoding cost adds latency |
| Photos with HDR or wide color | AVIF | Only one of the three with 10 and 12 bits |
| Transparent graphics on the web | AVIF or WebP | Alpha at a fraction of PNG's size |
| Email attachments | JPG | Every client opens it |
| Upload forms, marketplaces, ID portals | JPG | Allow-lists rarely include AVIF or WebP |
| Printing and office documents | JPG, or PNG for graphics | Software support |
| Editing masters and archives | Original format, PNG or TIFF | Avoid repeated lossy encoding |
The pattern is simple: modern formats for delivery, JPG for exchange, lossless for masters.
How do you serve AVIF and WebP with a JPG fallback?
Use the <picture> element. The browser walks the <source> list in order and takes the first type it supports, falling back to the <img>, as defined by the WHATWG HTML picture element:
<picture>
<source srcset="hero-1600.avif" type="image/avif">
<source srcset="hero-1600.webp" type="image/webp">
<img src="hero-1600.jpg" width="1600" height="900" alt="Mountain lake at sunrise">
</picture>
A browser with AVIF support downloads only the AVIF. One without AVIF but with WebP downloads the WebP, and everything else gets the JPG. No format is downloaded twice.
The alternative is server-side negotiation: the browser sends an Accept header such as image/avif,image/webp,*/*, and the server or CDN returns the best format it has from a single URL. This keeps markup simple but requires the cache to vary on that header, as described in HTTP's content negotiation rules in RFC 9110.
To generate the three versions in a build step, the Node.js library sharp writes all of them:
import sharp from 'sharp'
const input = sharp('hero-master.png').resize(1600)
await input.clone().avif({ quality: 50 }).toFile('hero-1600.avif')
await input.clone().webp({ quality: 80 }).toFile('hero-1600.webp')
await input.clone().jpeg({ quality: 82, mozjpeg: true }).toFile('hero-1600.jpg')
The quality values differ on purpose, since the scales do not correspond across formats. Check the output visually before settling on numbers.
How do you convert between AVIF, WebP and JPG without uploading?
Use a client-side converter, which decodes and re-encodes the image inside the browser tab so the file never leaves your device. The Toolz converters are split by direction.
From AVIF to something other programs accept. The AVIF to JPG converter is the fix for an AVIF saved from a website that a document or form refuses. Transparent areas are filled with white, and a note under the result says so. The Quality slider runs from 10 to 100 and starts at 90. When the image has a transparent background that must survive, convert the AVIF to PNG instead, which keeps the alpha channel and stores the decoded pixels losslessly.
Decoding AVIF uses the browser's own AVIF decoder, so the converter needs a browser that displays AVIF: Chrome, Edge, Firefox, or Safari 16 and later. If the browser cannot open the file, the row says so. An animated AVIF is read as a still image.
From WebP to JPG. For the same reasons, WebP to JPG turns a downloaded .webp into a file that opens everywhere, with the same white fill for transparency.
From JPG and PNG to WebP. Going the other way, JPG to WebP shrinks photos for publishing, and PNG to WebP does the same for screenshots and transparent graphics while keeping the alpha channel. Encoding uses the browser's canvas encoder. Current Chrome, Edge and Firefox can write WebP; a browser that cannot gets a clear error instead of a PNG renamed to .webp.
What the converters do not do. Toolz reads AVIF but does not write it, because browsers do not reliably expose an AVIF encoder to web pages. To produce AVIF files, use a build tool such as the sharp example above. The Image Converter accepts JPG, JFIF, PNG, WebP, AVIF, GIF, BMP, ICO, HEIC, TIFF, PSD, SVG, CR2, DNG and PDF and writes JPG, PNG, WebP, GIF, ICO, PDF and SVG, which covers mixed batches.
Every conversion is drawn through a canvas, so EXIF data, GPS coordinates and color profiles are not copied into the output. Images over 100 megapixels are refused with a message rather than crashing the tab. The tools are free, no signup, with a daily conversion limit.
Does converting between AVIF, WebP and JPG lose quality?
Converting into a lossy format loses some detail every time, and converting into a lossless format loses nothing further. The direction decides which applies.
| Conversion | Lossy step? | What changes |
|---|---|---|
| AVIF to JPG | Yes | Second lossy encode; transparency filled with white; file usually larger |
| AVIF to PNG | No | Decoded pixels kept exactly; transparency kept; file much larger |
| WebP to JPG | Yes | Second lossy encode; transparency filled with white |
| JPG to WebP | Yes | Second lossy encode on top of JPEG's; file usually smaller |
| PNG to WebP | Usually, with lossy WebP | Transparency kept; file usually much smaller |
| Any of them to AVIF | Yes, in typical use | Smallest file; slowest encode |
Two practical consequences follow. A file that has been through several lossy conversions degrades a little at each step, so avoid round trips such as JPG to WebP to JPG. And the size of a converted file tells you little about its quality: an AVIF converted to JPG gets larger without getting any better, because the JPG encoder spends more bytes describing the same already-compressed picture.
At a quality setting around 90, a single extra lossy step is very hard to see in ordinary photos. The losses become visible with repeated conversions, low quality settings, or images with fine text and sharp edges.
Why won't a saved AVIF or WebP open?
The program opening it has no decoder for the format. A current browser shows the image because it negotiated that format with the server, but the file on disk is then handed to software with an older or narrower list of formats: an office suite, an older photo viewer, an email client or an upload form's allow-list.
Renaming the file to .jpg does not help. The bytes still begin with an AVIF ftyp box or a WebP RIFF header, and a program expecting JPEG finds no JPEG data. Converting the file is the fix, and it is also worth checking whether the site offers a direct download link, which sometimes serves the original JPG or PNG rather than the negotiated version.
Is JPG obsolete?
No. JPG is obsolete only as the format a website should send to a current browser, and even there it remains the fallback in every <picture> element. As an exchange format, for email, forms, printing, office documents and anything headed to software you do not control, it is still the correct default, and neither AVIF nor WebP has replaced it.
The same logic applies to the other format that confuses people outside the browser. iPhone photos are HEIC, a sibling of AVIF in the same HEIF container, and the comparison of HEIC vs JPG explains why those files fail to open on Windows. Every image converter is listed on the image tools hub.
