AVIF, HEIC and In-Browser Compression Landed in Core

The most reliable way to break an upload on shared hosting has always been to send a 12-megapixel photograph straight from a phone into the media library and let PHP try to resize it. The failure modes are familiar — a memory limit, a timeout, a half-written thumbnail set — and the usual remedy was a plugin or a stern instruction to contributors. WordPress 7.1, released 19 August 2026, changed where that work happens.

Compression moved into the browser

The 7.1 release announcement puts it plainly: image compression, resizing and thumbnail generation now happen in the browser, reducing server load and producing smaller files — without hitting PHP memory limits or upload timeouts. The work is done with WebAssembly before the bytes leave the machine, which changes three things at once. Server CPU during upload drops, because PHP is no longer decoding and re-encoding a large raster. Upload bandwidth drops, because a compressed file is what travels. And the failure class behind most media support conversations stops occurring, since nothing large enough to exhaust a memory limit ever arrives.

The cost sits on the contributor’s device. A slow laptop encoding a batch of images will feel that, and the encode happens once per file per upload. For most editorial workflows that is a good trade; for a bulk import of several thousand product images it is worth testing rather than assuming.

AVIF, HEIC and what the visitor can decode

Core now natively supports AVIF, HEIC and HDR gain maps, described in the announcement as native support for the image formats modern cameras and phones already produce. The two formats sit at opposite ends of the pipeline and it is worth not conflating them.

AVIF is a delivery format. Google’s own guidance on compressing images with AVIF reports organisations observing greater than 50% savings against JPEG, and browser support arrived in Chrome and Opera in 2020, Firefox in 2021 and Safari in 2022. That is broad enough to serve by default with a fallback, and narrow enough that removing the fallback is still premature.

HEIC is an ingest format. It is what an iPhone writes, and decoding it is not general across browsers, so its value in 7.1 is that WordPress can now accept the file a contributor actually has rather than rejecting it. Treat it as something that enters the library and something else that gets served.

HDR gain maps carry extra data

A gain map is a second layer stored alongside a standard-dynamic-range image, describing how to brighten it on a display capable of showing the wider range. The same AVIF guidance notes that the format supports high dynamic range and wide colour gamut among its features. The implication that gets missed: a gain map is additional data in the file, so the same photograph with one is larger than the same photograph without. The release announcement does not quantify that, and it will vary by image, which is a reason to measure rather than to enable it across a catalogue on principle.

Where an image is decorative and small on screen, the gain map is paying for something almost nobody will see. Where it is a hero image on a product page, it may be worth the bytes. That decision belongs per template, not per site, and it interacts directly with an LCP optimisation pass because the hero image is usually the LCP element.

GIF to video, and the LCP consequence

7.1 also adds opt-in GIF-to-video conversion, which the announcement says produces typically smaller files. Animated GIFs are among the worst offenders in page weight because the format has no modern compression, and a short loop can outweigh every other asset on a page combined. Converting to video usually cuts that by an order of magnitude.

The conversion is opt-in, which is the correct default, because a video element and an image element do not behave identically. A converted animation is no longer eligible to be the LCP element in the way an image is, autoplay behaviour differs across browsers and data-saver settings, and anything relying on the file being a GIF — an email template, a syndicated feed, an external embed — will need checking.

What to check after upgrading

None of this is retroactive. Existing media keeps the format and file size it had; the changes apply to what happens next. Upload a photograph from a phone and note what is stored and what is served. Confirm your delivery layer or CDN is not re-encoding what the browser already compressed, which is duplicated work and occasionally a quality loss. Decide on GIF conversion deliberately rather than leaving it at the default and forgetting the setting exists. Check that alt text discipline survived the new upload flow, because a faster path to publish is a faster path to publishing without it — a point that matters more since AI-generated images and alt text became routine. And if the library feeds a product catalogue, re-read product image requirements before changing formats, since a feed has its own rules about what it will accept.