Your store converts images to AVIF. It will not let you upload one

A photographer sends the new season's shots as AVIF, because that is what a modern camera pipeline produces and the files are a third of the size. The merchandiser opens the product form, picks the file, and Magento says the file type is not allowed. So the images get converted to JPEG to be uploaded – to a store that then runs an extension converting them back to WebP on the way out.

The round trip is not a configuration mistake. Adobe Commerce and Magento Open Source hard-code which image types the admin accepts, and WebP and AVIF are not among them. That was still true when 2.4.9 shipped.

What it is for

WebP & AVIF Product Images removes the round trip. The formats become ordinary uploads – in the product form, the media gallery, swatches, Page Builder, the WYSIWYG editor, theme logos and customer uploads – and they are served as they are, from a plain <img> tag.

That last detail is the one worth pausing on. There is no <picture> element, no srcset juggling and no JavaScript on the storefront. The file the browser requests is the file on disk. Nothing in a theme has to change, and the behaviour is identical on Luma and Hyvä because there is no theme markup involved at any point.

What changes in the week: the conversion step leaves the workflow. Files arrive in the format they were made in and go out in the format they arrived in.

How it can be used

As the upload path, and nothing else. The smallest use: switch it on, and the formats stop being rejected. No migration, no conversion, no change to a single existing image. New images arrive modern, old ones stay as they are.

As a catalogue migration, once. One command converts existing JPEG and PNG files and rewrites the references that point at them. It previews with a dry run first, and it is idempotent – a second run over a converted catalogue is a no-op rather than a second conversion. The trade-off is stated plainly: this rewrites references in your catalogue, so the dry run is not decoration.

As automatic conversion on upload. Optional, off by default. Product images are converted as they are added, at a quality you set per format, so the merchandiser keeps working in whatever format they have and the store keeps a consistent one.

Tuned per store, or left alone. WebP and AVIF are separately switchable, each with its own encoder quality; the converter backend can be pinned to cwebp, ImageMagick or GD or left on automatic selection; and paths can be excluded by regular expression when some directory must stay untouched. All of it is per store view, and none of it has to be configured for the extension to do its job.

How it compares

Measured on 2026-09-03 by opening six live Marketplace listings in a browser, reading the price rendered for each edition rather than the one in the page's structured data – which, in this category, is wrong on four listings out of six.

Everything comparable files under Site Optimization → Performance and does the same thing: conversion on output. Existing JPEG and PNG files are converted to WebP, cached, and served to browsers that accept them, with a fallback for those that do not. On the Magento Open Source tier that shelf runs from USD 39.00 (MageComp) through 49.99 (Apptrian), 50.00 (FME), 59.00 (Plumrocket, BSS) to 99.00 (JaJuMa). The two with published ratings – JaJuMa and Apptrian – both hold 5.0 from three reviews.

Several of them are good at what they do, and two things they have are worth naming. JaJuMa's offers three converter backends, a dedicated converted-image cache, Varnish and full-page-cache compatibility and a built-in conversion test; if AVIF is wanted there it lives in a separate subscription product at USD 199.00 a year. And every one of them works with plain GD, where native serving here needs ImageMagick built with WebP and AVIF support – a real prerequisite, checked by a diagnostic command rather than discovered at the first upload.

What none of them does is change what the platform will accept. They operate one step later in the pipeline, on files that already got in. A merchant whose source images are AVIF still converts to JPEG to upload, and the conversion extension converts back. Buying one of them and this one is not a contradiction: they solve adjacent halves of the same sentence.

Three things here follow from working at the upload boundary:

The whole admin, not the product form. Media gallery, swatches, Page Builder, CMS and WYSIWYG, theme logos and customer uploads accept the formats too. A restriction lifted in one screen and left in five is worse than no change, because the failure moves rather than disappearing.

No storefront JavaScript and no database tables. The extension adds neither. There is nothing to purge, nothing to migrate on uninstall, and nothing on the critical rendering path.

The prerequisite is checked, not assumed. A preflight diagnostic reports whether the server can actually encode and serve these formats, and warns when Magento's image adapter is set to GD – which silently defeats native serving – rather than letting a merchant find out from a broken product page.

What it does not try to be

It is not a CDN, not a lazy-loader, not a page-speed suite, and not a converted-image cache with Varnish integration. It does not resize, crop or generate responsive variants. It is deterministic and on-premise: no external service, no telemetry, nothing leaves the server. The rest of the absences are in the FAQ on the extension's page.