Use WebP as your default web image format, and reach for AVIF only when the smallest possible file matters more than guaranteed rendering. AVIF usually wins on size, WebP on reach. Transparency, animation and metadata follow the same rules for both.
The choice is not obvious because reading and writing are separate abilities. A browser can display a format long before it can encode one, and that gap is wider than most guides admit. Chrome has decoded AVIF since version 85, yet the canvas API in every major browser still cannot encode AVIF at all: asking for an AVIF blob quietly returns PNG bytes instead. A WebAssembly encoder is the way around that, and it is what these tools use.
What follows is a decision table for today rather than a history of the two formats, the browser support behind it checked against caniuse and MDN on 2026-10-01, and a local conversion workflow with the Aihangsoft tools.
Most comparisons stall on benchmark charts, and a chart does not answer the real question: which file do I export from the image in front of me. The deciding factors are transparency, the browsers your visitors run, and whether you can encode the format at all.
The decision, in one table
Find your situation on the left and export what the middle column says. The third column is the reason, and the rest of the page expands on the rows that need it.
| Your situation | Export as | Why |
|---|---|---|
| A photo on a website, widest possible reach | WebP | Renders in every current browser, and browsers can also write it, so you can produce it locally |
| A photo on a website where bytes are a measured problem | AVIF, with a WebP or JPEG fallback | Smaller at the same visual quality, but a few older devices cannot display it |
| A logo, icon or screenshot with transparency | PNG, or WebP if the file is too heavy | Both carry an alpha channel; JPEG has none and would fill the transparent area |
| An email attachment, a form upload or old desktop software | JPEG | Read by software that predates both newer formats |
| An animated image | WebP, or GIF for maximum reach | Both handle animation widely; animated AVIF arrived later and is narrower |
| You already ship WebP and it works | Keep WebP, unless size is a proven problem | Moving to AVIF adds a fallback path and a slower encode for a gain you have not measured yet |
Two rows deserve a second look. JPEG is still the right answer whenever the file is going somewhere that is not a browser, because pickers and email clients validate the formats they were built to know. And "switch everything to AVIF" is the most common mistake in this area, and the least profitable one.
What actually differs between WebP and AVIF
Where the two formats come from
WebP was released by Google in 2010 and is built on the VP8 codec. It is a single container that holds lossy images, lossless images, transparency and animation, which is why it displaced two formats at once on the web instead of one.
AVIF is built on AV1, the codec also used for video, and was published by the Alliance for Open Media in 2019 inside the HEIF container. That lineage explains both its advantage and its cost: it borrows the efficiency of a modern video codec, and it inherits the slower encoding that comes with one.
File size, and why this page will not give you one number
For a JPEG baseline, Google's own WebP FAQ states that lossy WebP averages about 30 percent more compression than JPEG without a visible loss of quality. That claim comes from the format's authors and was re-checked on 2026-10-01.
The AVIF comparison is harder to state honestly. Encoder tests report that AVIF is smaller than WebP at equal visual quality, and that direction is consistent across sources. The size of the gap is not, because it swings with the image content, the quality target and the encoder build. Rather than quote a single percentage that would not survive contact with your own library, treat it as a one way statement: AVIF is usually the smaller of the two, and how much smaller is worth measuring on your own images.
Transparency, animation and metadata
Both formats carry a full alpha channel, so a logo with a soft shadow exports cleanly in either one. Animation is supported by both, but WebP animation has been in browsers for years, so an animated asset is safer as WebP.
Metadata is the quiet difference. Any conversion that redraws an image through a canvas rebuilds the pixels and drops the EXIF block, so camera information, capture time and GPS coordinates do not survive.
Browser support, checked against caniuse and MDN
Support is where the two formats separate, and it is worth stating the numbers with their source because they change. The WebP figures come from Google's WebP FAQ and the AVIF figures from the caniuse compatibility table, both checked on 2026-10-01.
| Format | Chrome | Firefox | Safari | Edge |
|---|---|---|---|---|
| WebP | 17 and later for lossy, 23 and later for lossless and alpha | 65 and later | 14 and later, including iOS 14 | 18 and later |
| AVIF | 85 and later | 93 and later | 16.4 and later for full support, partial from 16.1 | 121 and later |
The caniuse table places AVIF at roughly 95 percent global availability as of 2026-10-01. The remaining fraction is what matters, because it is not evenly spread: almost all of the gap sits on Safari versions before 16.4, older iPhones and iPads that will never be upgraded, and on Edge installations older than 121.
WebP has no comparable gap. Every browser that renders a modern page also renders WebP, and Safari has supported it since 14. When someone asks whether WebP is safe to ship, the answer has been yes for years.
Image Converter
Convert JPG, PNG, WebP, AVIF and GIF inputs to WebP, PNG, JPEG or AVIF in one batch. Runs in your browser, so the files are never uploaded.
Should you move from WebP to AVIF?
This is a different question from which format is better, and it has a practical answer. Ask three things about your own site before you touch a single file.
- Who actually visits? Look at the browser breakdown in your analytics. If almost everything is a current Chrome, Safari or Firefox, an AVIF first strategy costs nothing. If a visible slice is on iOS below 16.4, you need a tested WebP fallback in the markup.
- What would you gain? Bytes only matter where they change something a user can feel, such as a hero image or a long gallery. A 40 KB thumbnail that becomes 32 KB will not move a Core Web Vitals number, and converting a thousand of them is work with no measurable return.
- What does the switch cost? Every AVIF image needs a fallback source or a CDN that negotiates formats for you. That is a real change to your markup or your hosting, not a file rename.
The sensible order is to leave the existing library alone and convert new, large images to AVIF behind a picture element, keeping WebP as the second source. Revisit the backlog only if your measurements show image weight is the bottleneck.
How to convert a batch without uploading anything
Both Aihangsoft image tools run the job inside the browser tab: most formats use the canvas encoder the browser already has, and AVIF uses a WebAssembly build of libavif. Nothing is sent anywhere, and there is no account or per batch counter.
- Add your images. Drop files onto the upload area or click to browse. JPG, PNG, WebP, AVIF and GIF are accepted, and you can add as many as you like in one go.
- Pick the output format. Choose WebP, PNG, JPEG or AVIF. In the Image Converter the lossy quality is fixed at 0.92, so the format is your only decision. To trade quality for size, use the Image Compressor instead, which adds a 1 to 100 slider, an optional resize, and a lossless pass for PNG output.
- Convert and download. Press convert, then save each result or download the whole batch. Files are processed one after another on your machine, so a large batch takes as long as your own hardware needs.
Image Compressor
If the output is already the right format but too heavy, compress it here. A quality slider up to 100, an optional resize, and a live before and after comparison.
What these tools cannot do
- Conversion changes the container, not the picture. Re-encoding cannot add detail that is not there. A soft or noisy photo will not become sharp by converting it to WebP or AVIF. Use an image upscaler for that, and keep the format question separate.
- Repeated lossy conversions accumulate damage. Each pass through JPEG, WebP or AVIF discards a little more. Convert once from the original file, never from a copy you already converted.
- The converter's lossy quality is not adjustable. The Image Converter writes every lossy output at a fixed 0.92. That is a deliberate default, not a full control panel. If the file is still too heavy, take the result to the Image Compressor and use the slider there.
- AVIF output costs a download before it works. No browser can encode AVIF from a canvas: the specification requires an unsupported request to come back as PNG, with no error raised. Both tools therefore ship a WebAssembly build of libavif, which runs in a worker inside the page and never uploads the image. The trade is that the first AVIF run downloads about 3.5 MB and encodes more slowly than WebP. If that download fails, the tool falls back to WebP and says so in the status line.
- HEIC files will not open. Browsers cannot decode the HEIC format that recent iPhones write by default, so those files fail with a short error. On the phone, change the setting under Settings, Camera, Formats to Most Compatible to get JPEG files from then on.
- An animated input becomes a still image. A GIF can be added as an input, but the converter draws a single frame to a canvas, so the animation is not carried over to the output.
- JPEG has no transparency. Exporting an image with a transparent background to JPEG gives you that area filled in, and both tools fill it with white. Choose PNG, WebP or AVIF to keep the alpha channel.
- There is no server behind the work. Because nothing is uploaded, nothing can be offloaded either. Speed and memory come from your device, so a very large image or a long batch is limited by the machine in front of you rather than by a plan.