WordPress 7.1 ships client-side media processing: your browser, not your server, handles compressing, resizing, format-converting, and rotating images before they upload, using a WebAssembly build of the libvips image library. Confirmed browsers get faster uploads and lighter server load; everyone else falls back to the old server-side process automatically, with no visible difference. This is confirmed to ship in WordPress 7.1, per the official WordPress 7.1 Field Guide published August 5, 2026.
Status as of August 11, 2026: confirmed shipping, currently in the WordPress 7.1 beta, with final release targeted for August 19, 2026.
The short version
- What it is: image processing (compress, resize, crop, rotate, format-convert, generate thumbnails) runs in your browser before the file uploads, instead of on your server after.
- The technology:
wasm-vips, a WebAssembly compilation of the libvips library, running in a Web Worker so it doesn't freeze your browser tab. - Formats covered: JPEG, PNG, WebP, AVIF, GIF (including animated GIF-to-video conversion), and HEIC/HEIF, the default format for iPhone photos.
- Browser support: Chrome and Edge 137+ get full client-side processing. Firefox and Safari fall back to server-side processing automatically.
- What doesn't change: the server still validates every uploaded file and runs your existing WordPress filters. This isn't a security bypass, it's where the resizing work happens.
What client-side media processing actually does
Until now, every image you uploaded to WordPress was processed entirely on your server: your host's PHP process (via Imagick or GD) resized the original into your theme's registered sizes, generated thumbnails, and handled any rotation or format conversion. That work costs server memory and CPU on every single upload, which is part of why large or bulk image uploads can time out on modest shared hosting.
WordPress 7.1 moves that work into the browser instead, using wasm-vips, a WebAssembly build of libvips, a high-performance image library, running inside a Web Worker so the processing happens on a background thread and doesn't lock up your editing session. The supporting packages named in WordPress's own technical writeup are @wordpress/upload-media for queue management, @wordpress/vips as the Web Worker wrapper, and @wordpress/video-conversion for the GIF-to-video path specifically.
Practically: in a supported browser, you select or drag an image into the block editor, and compression, resizing, EXIF rotation, and format conversion happen locally before the file leaves your device. The server still receives the file, validates it, and runs whatever media filters your plugins register, but it no longer has to do the processing work itself.
Formats and operations, per the official record
| Category | Supported |
|---|---|
| Image formats | JPEG, PNG, WebP, AVIF, HEIC/HEIF, gain-map HDR (UltraHDR JPEGs) |
| Operations | Compression, resizing, cropping, EXIF rotation, progressive/interlaced encoding, thumbnail generation |
| Video-adjacent | Animated GIF converted to video for lighter file sizes |
| Reliability | Upload progress indicator; automatic retry if the connection drops mid-upload |
HEIC support is worth calling out specifically: it's the default photo format on recent iPhones, and until now WordPress sites have needed a plugin or server-side conversion step to handle it cleanly. Native browser-side HEIC handling closes that gap without any extra configuration.
Requirements, and when it quietly falls back to the server
Client-side processing only runs when the browser and server environment both support it. WordPress's own technical documentation lists specific thresholds:
| Requirement | Threshold |
|---|---|
| Browser | Chrome or Edge 137+ (full WebAssembly support) |
| Device memory | More than 2 GB |
| CPU cores | 2 or more |
| Network | Faster than a 2G connection |
| Server headers | Document-Isolation-Policy: isolate-and-credentialless |
| Content Security Policy | Must allow worker-src 'self' blob: |
If any of those aren't met, most notably on Firefox and Safari, which fall back automatically regardless of the other thresholds, WordPress 7.1 uses the existing server-side processing path. The stated design goal is that this fallback is invisible to the person uploading: no error, no missing feature, just the same image handling WordPress has always done. If your host's PHP setup doesn't have Imagick or GD configured well, that's a separate, existing problem this feature doesn't fix for you on unsupported browsers, since the fallback still depends on your server's own image libraries. If you're unsure what your host is running, our guide to checking your PHP version covers where to find that information in Site Health.
What we haven't tested ourselves, and why that matters here
Everything above is what WordPress's own core-development record says the feature does. What we have not done, because WordPress 7.1 is still in beta as of this writing, is upload a real batch of images through it ourselves and time the difference against server-side processing on an actual shared-hosting account. That's a meaningful gap for a feature whose entire pitch is speed and reliability: the requirements table above tells you whether the feature will activate on a given visitor's device, but not how much faster an upload actually feels in practice, whether the automatic retry behaves well on a genuinely flaky connection, or whether any WordPress plugins that hook into image processing (watermarking, custom size generation, CDN offload) behave differently when the browser has already done the resizing. We'll update this page with first-hand upload testing once WordPress 7.1 has shipped and we've run it against a real site, rather than guess at numbers we haven't measured.
What this means for your uploads, practically
If you and your visitors are mostly on Chrome or Edge, expect faster image uploads in the block editor and less strain on your server during bulk uploads, since the heavy lifting moves to the browser. If you're on Firefox or Safari, or your device is under the memory or CPU thresholds above, nothing changes for you: WordPress quietly uses the same server-side process it always has. Either way, no action is required to get the fallback behavior; it's automatic. If you're evaluating whether to update to WordPress 7.1 at all, this feature is a genuine day-one improvement rather than something to wait on, but it's one factor among several covered in our broader WordPress 7.1 rundown.
For the wider context on what's in this release and what got left out, our WordPress 7.1 overview covers the full feature list, and the companion status page on real-time collaboration in WordPress covers the other in-flight core effort people ask about alongside this one. If you're new to reading WordPress's own release documentation rather than relying on summaries like this one, our guide to reading a WordPress release note is a good next stop, and the WordPress 7.x guide for site owners is the standing reference this page sits under.
FAQ
Does client-side media processing replace my server's image processing entirely? No. It only runs in supported browsers (Chrome/Edge 137+) under specific device and network conditions. Unsupported browsers and devices fall back automatically to the same server-side processing WordPress has always used.
Do I need to change any settings to use it? No. There's no toggle to find; it activates automatically when your browser and connection meet the stated requirements, and falls back automatically when they don't.
Will this make WordPress uploads faster on my site? For visitors on a supported browser and device, yes, per the feature's design goal, since resizing work moves off your server. We haven't independently measured the speed difference ourselves yet; see the testing gap noted above.
Does this affect image quality or format compatibility? The supported formats (JPEG, PNG, WebP, AVIF, HEIC/HEIF, animated GIF) are processed with the same libvips-based engine either way, client-side or server-side, so format support shouldn't differ. We haven't run a side-by-side quality comparison ourselves.
Is this related to real-time collaboration also being discussed for WordPress 7.1? No, they're separate efforts. Real-time collaboration was tested during the WordPress 7.1 cycle but did not make the final release; client-side media processing is confirmed shipping. See our status page on real-time collaboration for that separate question.
Written against the WordPress 7.1 beta and the WordPress 7.1 Field Guide (make.wordpress.org, August 5, 2026) as of August 11, 2026. WordPress 7.1's final release is targeted for August 19, 2026; beta features can still change before then.
