WordPress 7.1 Just Moved Image Processing to Your Browser

WordPress 7.1 “Mary Lou” shipped on August 19, 2026, and the headline feature isn’t a new block or a styling panel — it’s a quiet architecture change that affects every image uploaded to your site.

Until now, every image you uploaded was processed on your server. WordPress passed the file to PHP, which used GD or Imagick to resize it, generate thumbnails, fix EXIF rotation, and convert formats. That’s why a single 12MP phone photo could occasionally choke a shared host, and why “allowed memory size exhausted” errors during uploads were such a common WordPress headache.

WordPress 7.1 introduces client-side image processing. In supported browsers, resizing, format conversion, EXIF rotation, and thumbnail generation happen in the browser before upload. When not supported, WordPress falls back to the traditional server-side processing — so nothing breaks. This is implemented as a progressive enhancement, not a replacement.

What Actually Changes for Your Site

A few things are worth knowing before you plan around this:

• Lower server load. Uploads no longer hammer your server’s CPU or hit PHP memory limits, since the browser does the resizing and conversion work instead.
• Smaller output files. Images generally come out smaller after processing, which means faster page loads for your visitors without any extra work on your end. This complements the usual image SEO best practices around file names, alt text, and compression — smaller files from the upload process are one less thing you need to optimize manually.
• Broader format support. WordPress can now decode AVIF, HEIC (common on iPhones), and HDR gain maps in the browser and convert them to web-friendly formats during upload.
• A real security upgrade. Server-side image libraries like GD and Imagick have a long history of parser vulnerabilities, some exploitable just by uploading a malformed image. Moving that decoding into the browser’s sandbox means untrusted files are processed on the visitor’s machine before your server ever touches them.
• Your existing settings still apply. Filters like big_image_size_threshold and image_editor_output_format continue to work without changes, and the old server-side image editor stays in place as a fallback for anything the browser can’t handle.

This also means image processing quality becomes consistent across hosts, since it no longer depends on server libraries like GD or Imagick.

The One Catch: Browser Support

Client-side processing depends on a browser feature called Document-Isolation-Policy, which enables SharedArrayBuffer. Right now, that’s only available in Chromium-based browsers — Chrome and Edge have supported it since version 137, and Chrome on Android supports it from version 146. Since most Chromium users are already well past those versions, this covers the overwhelming majority of your site’s editors and visitors, but it’s not universal yet. When the browser can’t do it, WordPress quietly falls back to the old server-side path, so nothing breaks — uploads just process the way they always did.

What to Check Before You Update

WordPress 7.1 shouldn’t break a standard site running up-to-date themes and plugins. The real risk sits with plugins that hook into the image upload process directly, and with any custom code built against the old server-side assumptions. If that sounds like your setup, test on a staging copy first:

• Upload a batch of images, including at least one HEIC or AVIF file, and confirm thumbnails generate correctly
• Check any plugin that processes, watermarks, or optimizes images on upload
• Confirm your registered custom image sizes (via add_image_size()) still generate as expected
• Take a full backup before updating the live site regardless

For most WordPress sites, this is a genuinely useful release. Slow uploads and PHP memory errors during media uploads have been a persistent, if unglamorous, pain point for years, and this fixes it without asking site owners to do anything differently.