Convert AVIF to WEBP
Re-encode an AVIF as WEBP for software that will not open the newer format, accepting a larger file in exchange.
How it works
AVIF and WEBP both descend from video codecs, and the newer one wins on compression by a wide margin. Going the other way trades bytes for reach: the output is larger, and the software that refused the input will accept it. This is a deliberate step down a compatibility ladder rather than an upgrade, so the useful thing a page can do is price the step.
The programs that send people here
Adobe's documentation dates full WEBP handling, meaning open, edit and save with no plug-in, to Photoshop 23.2 in February 2022. AVIF export arrived only with the June 2025 release. A machine pinned to an older Creative Cloud version reads one format and not the other, and the gap between those two dates is over three years.
Shopify's product media documentation lists the upload formats a store accepts: PNG, JPEG, PSD, TIFF, BMP, GIF, SVG, HEIC, WEBP. AVIF is absent from that list, while Shopify's own delivery pipeline serves AVIF to browsers that advertise support for it. The platform will hand your customers an AVIF and will not take one from you.
On Windows, an AVIF thumbnail in File Explorer and a preview in the Photos app both depend on the free AV1 Video Extension from the Microsoft Store, a requirement AOMedia states in its own announcement of the format. WEBP needs nothing installed. In the browser the gap closed years ago, since Safari 14 shipped WEBP in September 2020 as the last holdout.
The size arithmetic, measured
Figures from this session. The master is an 800×600 photograph whose alpha covers most of the frame: 96.4% of its 480,000 pixels are less than fully opaque, and the PNG holds 224,566 bytes. Encoded to AVIF at quality 82 it comes to 34,237 bytes. Converting that AVIF to WEBP at the same quality produced between 75,270 and 75,790 bytes over six runs, since libwebp's lossy output shifts a little between runs. Call the result 2.2 times the AVIF.
Encoding WEBP straight from the master's own pixels gave 75,796 to 76,014 bytes, inside the same band, so the extra generation costs no measurable bytes. What it costs is fidelity. Composited onto white and compared with the master, the AVIF sits at 46.2 dB PSNR and the WEBP at 28.0 dB: the same quality number buys 18 dB less in the older codec.
AVIF therefore stays the file to serve over a network, and the WEBP is the copy handed to whatever cannot open it. Keep both. Converting and then deleting the AVIF discards the smaller asset to satisfy one program.
Where WEBP wins outright
WEBP's lossless mode is a separate bitstream from its lossy one rather than a setting on it. VP8L codes exact pixels using backward references, a colour cache and reversible colour transforms, and on flat graphics that beats PNG. Measured on one of this site's own 1200×630 preview cards, the PNG holds 24,000 bytes and WEBP lossless stores the identical pixels in 10,660, taking about 20 ms.
AVIF's answer to the same job costs far more. Encoding that card at quality 100 ran for roughly 390 ms on this machine and produced 24,580 bytes, larger than the PNG it came from. Nineteen times the time for a worse result. On a screenshot or a diagram, WEBP is the better format on both axes rather than the more compatible one.
A second lossy pass
One caveat outweighs the size. An AVIF has already discarded detail, and this tool reproduces what survived rather than what the camera recorded. The cost shows up in what happens next: storing the AVIF's decoded pixels as lossless WEBP takes 186,632 bytes, while storing the master's pixels the same way takes 158,326, an 18% penalty. A decoded picture is harder to code exactly than the original, and the av1C record in this file declares 4:2:0, so the decoder interpolated half the colour samples it handed over.
A converted copy therefore makes a poor master. Where the original PNG or camera file still exists, convert that and skip a generation, because running this WEBP through another lossy encoder compounds the same arithmetic again.
Alpha needs no decision here: all 480,000 alpha values in the test file came back byte-identical through the lossy WEBP encode on three consecutive runs, since libwebp codes the alpha plane losslessly whatever the quality setting says, so nothing is flattened and no background colour is asked for.
The AV1 decoder and the libwebp encoder are WebAssembly modules running in a Web Worker on your own machine. There is no queue and no ceiling beyond the memory your device has.
Questions
Why did the file get bigger?
Because AV1 intra coding compresses harder than VP8 does. On the test image described above the WEBP landed near 75,500 bytes against the AVIF's 34,237, about 2.2 times, and the result panel reports the exact delta for your own file before you download it. Lowering the quality slider closes the gap by removing more detail. No setting makes WEBP match AVIF at a matched appearance.
Does the file leave this tab?
No. Open developer tools, select the Network tab, then run a conversion: every request listed is same-origin and fetches code or a WebAssembly module, and none carries image data. The decode and the encode both happen inside a Web Worker in this page.
When is lossless the right setting here?
When the AVIF holds a screenshot, a diagram or a logo rather than a photograph, because flat regions and hard edges are what VP8L codes well. On a photograph it is the wrong choice: the lossless WEBP made from the test AVIF weighed 186,632 bytes, five and a half times the AVIF, and those bytes went on storing the smoothing the AVIF had already applied.
What happens to the alpha channel?
It comes through untouched. AVIF stores alpha as a separate auxiliary image inside the container, WEBP has an alpha plane of its own, and libwebp codes that plane losslessly even when the colour is lossy. Checked on the test file: all 480,000 alpha values were byte-identical before and after, so there is no background colour to pick and nothing to flatten.