WebP & AVIF Product Images
/
Slow, heavy product images hurt page speed and Core Web Vitals, yet Adobe Commerce and Magento Open Source block modern image formats by default – the admin refuses WebP and AVIF uploads, and the storefront serves only legacy JPEG/PNG. A fashion retailer with 4 000 product photos cannot switch to WebP at all without patching core. WebRamos Modern Images closes that gap so your catalogue can use modern formats that are typically 25 – 50 % smaller than an equivalent JPEG.
The extension does two things. First, it removes the hard-coded format
allow-lists wherever Magento enforces them – so your team can upload .webp
and .avif to product images, the Media Gallery, swatches, Page Builder, the
CMS image manager and theme logos; an integration can post them to the REST and
GraphQL product media API; and a shopper can attach one to a customer or
address file field on the storefront. Second, it lets Magento resize and
deliver those modern files as ordinary images through its own ImageMagick image
adapter – served as a plain <img> tag, with no <picture> markup and no
JavaScript. Because nothing is injected into the theme, the result behaves
identically on Luma and Hyvä.
A built-in command-line tool migrates an existing catalogue: it converts your current JPEG/PNG product images to WebP (or AVIF) and rewrites the catalogue references in a single, idempotent pass, with a dry-run preview and a safety confirmation. An admin diagnostics panel reports which converters are available and warns when the server's image adapter is not configured for ImageMagick, so you always know the environment is ready.
Modern Images is a rule-based, deterministic, on-premise extension. It uses no external services, sends no data off-site, adds no database tables and no storefront scripts. Encoder quality, converter backend and path exclusion are scoped per store view, so you can roll modern formats out on one store at a time; the extension's master switch is global, because what it governs is a catalogue-wide command.
Key Features
- Accept WebP and AVIF uploads across the admin (product images, Media Gallery, swatches, Page Builder, CMS/WYSIWYG, theme logos), the REST and GraphQL product media API, and storefront customer file uploads
- Native serving as a plain `<img>` – no `<picture>` element, no JavaScript
- Theme-independent: identical behaviour on Luma and Hyvä
- One-command catalogue migration (existing JPEG/PNG → WebP/AVIF + reference rewrite) with dry-run preview and idempotent re-runs
- Per-store configuration of encoder quality, converter backend and path exclusion
- Multiple converter backends (cwebp, Imagick, GD) with automatic selection
- Built-in preflight diagnostics with an image-adapter warning
- Path exclusion via regular expressions
- No database tables, no storefront JavaScript
Versions
Fix release for stores that run Modern Images as their only Webmaster Ramos extension.
Show details Hide details
Fixed
- Stores → Configuration no longer fails on a store where Modern Images is the only Webmaster Ramos extension installed. The extension now declares its own Webmaster Ramos configuration tab; it used to rely on another Webmaster Ramos extension declaring it, and without one every configuration page returned an error.
Fixes WebP and AVIF upload over the REST API and on the storefront, and replaces the two format switches with one Enabled switch.
Show details Hide details
Changed
- Enable WebP and Enable AVIF are replaced by a single Enabled switch in Stores → Configuration → WebRamos → Modern Images → General. The two settings controlled nothing. What they gated – conversion when a product image is saved – was removed in 1.1.0, and neither the migration command nor the admin's acceptance of WebP and AVIF uploads ever consulted them. Encoder quality for each format is unchanged and still set separately.
bin/magento webramos:modernimages:migratenow respects that switch. With the extension disabled it names the setting, converts nothing and reports success: declining to act on a setting you chose is not a failure, and a script that calls the command on a disabled installation should not stop.- The new switch is global, not per store view. It governs a catalogue-wide command, and – since this release – which image formats the installation accepts at all, in the admin, through the API, and in the media browser alike. Encoder quality, converter backend and path exclusion remain per store view.
- With the switch set to No, every place this extension opened up goes back to Magento's own list: the admin upload forms, the REST and GraphQL image API, and the CMS media browser all stop admitting new WebP and AVIF uploads. Already-stored WebP and AVIF files are untouched and keep being served – but the media browser stops listing them while the switch is off. The browser still lets a file be picked; the server is what refuses it.
- The extension's own check command now warns about the image adapter whether the switch is on or off, because images already converted still need ImageMagick to be served.
Removed
Configuration paths
webramos_modern_images/general/enable_webpandwebramos_modern_images/general/enable_avif.This can break a deployment script.
bin/magento config:seton either path now printsThe "…" path doesn't exist. Verify and try again.and exits with a non-zero status, so a provisioning run carrying either line stops. Replace both with the singlewebramos_modern_images/general/enabled. We are naming this plainly because it is a break in a release whose number does not normally signal one: check any provisioning or deployment script for these two settings before you upgrade.A value stored by an earlier version survives the upgrade as an orphan – Magento removes nothing for a path an extension stops declaring – and will appear in
app/etc/config.phpafter the nextbin/magento app:config:dump. Delete both rows if you set them.
Fixed
- Uploading a WebP or AVIF image through the REST API now works.
POST /V1/products/<sku>/mediarefused a genuine.webpwith HTTP 400 andThe product can't be saved.– with the extension installed, enabled, and accepting the same file everywhere in the admin. It had never worked, in any released version, although the image API has been described as an accepted upload path since 1.0.0. If you tried it and gave up, it was not your configuration: the code that widens Magento's image-format check was registered for the admin area only, so the API never loaded it. It is now registered for the whole installation. - A customer uploading a file on the storefront gets the same formats an administrator does. Where a customer account or address attribute accepts a file, WebP and AVIF were accepted when an administrator uploaded it and refused when the customer did. Both now behave the same.
- Both paths follow the Enabled switch like every other: set it to No and they refuse WebP and AVIF again.
Names the extension and its version in the support banner, and keeps the configuration page working when another module's composer.json is malformed.
Show details Hide details
Added
- The support banner in Stores → Configuration → WebRamos → Modern Images →
General now identifies the extension: a second line shows
WebRamos_ModernImagesfollowed by the installed version – the exact string to paste into a support ticket. Nothing on that pane named the extension before, and the version appeared nowhere in the admin at all. Both values are read from the installation itself, never hard-coded, so the line is always accurate. If the version cannot be determined, the extension name is shown alone rather than an incomplete line.
Fixed
- A malformed
composer.jsonin any other installed module can no longer break the rendering of this extension's configuration page – the version lookup now falls back to showing the extension name instead of letting the error escape into the form. No setting, no schema and no command-line output changes.
FAQ
Adobe Commerce and Magento Open Source decide which image types the admin will accept, and WebP and AVIF are not on the list – still not, in 2.4.9. A merchant whose source images are already in a modern format has to convert them to JPEG to upload them, into a store that may then convert them back on the way out.
This extension makes the formats ordinary uploads across the whole admin panel,
and serves them exactly as uploaded, from a plain <img> tag. The conversion
step leaves the workflow, and the files a browser downloads are a fraction of
the size a JPEG would have been.
- Your source images are already WebP or AVIF. A modern camera or design pipeline produces them, and every upload currently costs a conversion.
- You want smaller images without touching the theme. Serving is a plain
<img>; there is no<picture>element to add, nosrcsetto maintain and no storefront JavaScript. - You run Luma and Hyvä side by side. Behaviour is identical on both, because no theme markup is involved at any point.
- You have a catalogue of JPEG and PNG to move once. One command converts it and rewrites the references, with a dry run first and safe re-runs.
- Your server has ImageMagick with WebP and AVIF support. This is a prerequisite, not a nicety – see the last question.
- What you actually want is conversion on output. If your images are JPEG and will stay JPEG, and you want the store to serve WebP copies to browsers that accept them, buy a conversion extension. Several on the Adobe Commerce Marketplace do that well, from about USD 39, and two of them carry 5.0 ratings. This extension is about what the platform accepts, not about converting what it already has.
- You need a converted-image cache, Varnish integration or a
<picture>fallback for very old browsers. Those belong to the conversion products. - You are looking for a page-speed suite. Lazy loading, critical CSS, JS bundling and CDN delivery are all outside this extension.
- Your host gives you GD and nothing else. Native serving needs ImageMagick compiled with WebP and AVIF support. Without it the extension will tell you so, and it will not work around it.
- Accepts WebP and AVIF across the whole admin – product images, the media gallery, swatches, Page Builder, CMS and the WYSIWYG editor, theme logos and customer uploads. Not one screen: all of them.
- Serves them natively, as a plain
<img>. No<picture>element, nosrcsetrewriting, no storefront JavaScript, no theme changes. - Behaves identically on Luma and Hyvä, because there is no theme markup in the path.
- Migrates an existing catalogue with one command – converts JPEG and PNG and rewrites the references that point at them, with a dry-run preview, and idempotent so a second run is a no-op rather than a second conversion.
- Is configured per store view: an encoder quality for WebP and for AVIF, a
converter backend pinned to
cwebp, ImageMagick or GD or left on automatic selection, and path exclusion by regular expression. The extension's master switch is the one exception – it is global, because what it governs is a catalogue-wide command rather than anything a single store owns. - Checks the server before you trust it. A preflight diagnostic reports whether the host can encode and serve these formats and warns when Magento's image adapter is set to GD, which silently defeats native serving.
- Adds no database tables and no storefront JavaScript, and calls no external service.
- It does not work on GD alone. Native serving requires ImageMagick built with WebP and AVIF support, and Magento's own image adapter must be set to ImageMagick – with GD selected, the platform rejects the formats server-side whatever this extension is configured to do. The diagnostic command reports both conditions, and this is the single most common reason an installation does not behave as expected.
- It does not cache converted images or integrate with Varnish. There is no dedicated image cache; that is a conversion product's job.
- It does not emit a
<picture>fallback. A browser that cannot display AVIF gets no substitute, which is a deliberate trade for having no theme markup and no JavaScript. Current browser support is broad, but it is not universal, and this is the assumption to check against your own analytics. - It does not resize, crop, or generate responsive variants, and it is not a lazy-loader, a CDN or a page-speed suite.
- It does not convert your images for you, at any point. There is no conversion on upload and none at request time: a file is stored in whatever format you uploaded, and Magento's own resized copies inherit that format. The one exception is the migration command, which you run deliberately, once.
- It cannot undo a migration. The command rewrites references; the dry run is there so the decision is made before, not after.
- It sends nothing anywhere. No external service, no telemetry, no account. That is a limit as much as a feature: there is no vendor-side optimisation pass, and the quality you get is the quality your own encoder produces.