On June 10, 2026, the WordPress Developer Blog published its monthly roundup and buried in the highlights was a testing call that will reshape how every WordPress site handles images. WordPress is rolling out client-side media processing — a feature that moves image resizing, compression, and format conversion from your web server directly into the visitor's browser using WebAssembly. The feature is currently in testing for WordPress 7.1, and if you upload images to your site, this is the single most important performance change heading your way.

Here is the short version. Right now, when you upload a 4 MB photo from your phone to the WordPress media library, that file travels to your server, which then uses PHP and ImageMagick to generate thumbnail sizes, compress the image, and store multiple versions. On a cheap shared hosting plan, that process can take several seconds. On a bad day, it times out entirely. With client-side processing, your browser does all of that work before the file ever leaves your machine. The server receives pre-processed, pre-compressed images that are ready to store. The result is faster uploads, lower server CPU usage, and support for image formats that most servers cannot handle today.

How it actually works

The technical foundation is wasm-vips, a WebAssembly build of the libvips image library that runs inside the browser at near-native speed. When you drag an image into the WordPress block editor, the browser detects whether it can run WebAssembly (Chromium-based browsers currently support this). If it can, wasm-vips takes over: it reads the original image, generates all the thumbnail sub-sizes your theme requires, compresses them using the optimal codec, and sends the finished files to WordPress for storage. If the browser cannot handle it — Safari, older Firefox versions, or devices with limited memory — WordPress silently falls back to the existing server-side processing. No errors, no broken uploads, no user-visible difference.

The scope of what this unlocks goes far beyond faster uploads. The wasm-vips pipeline supports AVIF, WebP, HEIC, JPEG XL, and Ultra HDR formats natively. That means when someone uploads a photo from their iPhone in HEIC format — which most servers cannot process without additional software — the browser converts it to WebP before it even arrives at your server. The GitHub tracking issue for this feature lists MozJPEG encoding as well, which lets JPEG files approach WebP compression levels while remaining compatible with every browser on earth.

What this means for your server

The WordPress team claims this feature can reduce server-side image processing CPU usage by more than 80%. That number matters if you are running on shared hosting where your host throttles CPU usage, or if you have ever seen the "fatal error: allowed memory size exhausted" message after uploading a large image. The server's job shrinks from "resize, compress, convert, and store" to just "store." Your hosting bill does not change, but your site becomes meaningfully faster for anyone who manages content.

There is also a GIF-to-video conversion pipeline using ffmpeg.wasm, another WebAssembly library. Animated GIFs are the internet's favorite performance disaster — a 10-second GIF can easily be 15 MB, while the same animation as an MP4 is under 1 MB. With client-side processing, WordPress can convert GIFs to MP4 or WebM in the browser before upload, which means smoother playback, smaller files, and better mobile performance without installing a separate plugin.

The catch

This feature only works in Chromium-based browsers right now — Chrome, Edge, Brave, Opera, and Arc. Safari and Firefox users will get the old server-side processing until those browsers catch up on WebAssembly capabilities. The WordPress team has been clear that this is a progressive enhancement, not a replacement. Your server-side image processing still works exactly as it did before. The browser-based path is just faster when available.

There is also a testing gap. The feature is available for developer testing through a pull request on the Gutenberg repository, but it has not shipped in a stable WordPress release yet. The June developer roundup calls it "ready for testing," which in WordPress release terms means it is targeting 7.1 but could slip to a later version if testing surfaces problems. If you run a plugin that customizes image uploads, generates thumbnails, or modifies image metadata, now is the time to test against this feature and report issues.

What to do right now

If you are a site owner, there is nothing to install and nothing to configure. This will arrive as a core WordPress feature when it ships. What you can do today is make sure your current setup is not fighting it. Check that your hosting supports the latest PHP version (8.1 or higher), because older PHP versions may not play well with the new media handling paths. If you use an image optimization plugin like ShortPixel, Imagify, or Smush, keep it updated — those plugins will need to account for client-side processing to avoid double-compressing images. And if you have been putting off testing WordPress 7.0, this is another reason to get your staging environment ready, because the jump from 6.x to 7.1 is going to be the biggest media-handling change WordPress has made in a decade.

The shift from server-side to browser-side image processing is not flashy. It will not generate headlines or Twitter threads. But for anyone running a WordPress site on shared hosting, dealing with upload timeouts, or wondering why their image-heavy pages are slow, this is the fix that has been years in the making.