Client-Side Media Processing in WordPress 7.1: What You Need to Know

WordPress is advancing its media handling with client-side image processing set to debut as a core feature in version 7.1. This shift offloads resizing and encoding tasks from servers to users’ browsers, potentially transforming media upload workflows and hosting resource demands.

Client-side media processing uses the wasm-vips library to decode, resize, and encode images directly in the browser before upload.
This approach supports modern image formats like AVIF, WebP, HEIC, UltraHDR, and JPEG XL, improving compression and quality consistency across hosts.
It reduces server CPU and memory load during uploads, benefiting high-traffic or resource-constrained hosting environments.
Testing is crucial to validate performance, compatibility, and fallback reliability before WordPress 7.1 release.
Developers and agencies should test image uploads—especially varied formats and large batch uploads—using the latest Gutenberg plugin on Chromium browsers.

What Happened

WordPress core contributors have developed a client-side media processing pipeline that runs image manipulation tasks in the user’s browser rather than on the server. This technology harnesses the VIPS image processing library compiled to WebAssembly (wasm-vips), enabling browsers to decode, resize, and encode all image sub-sizes locally before sending uploads to the server.

The project started as a Gutenberg plugin experiment and matured during the 7.0 development cycle. It is now scheduled for integration into WordPress 7.1 as a core feature. The feature is designed to enhance the media upload experience by supporting advanced image formats such as AVIF, WebP, HEIC, UltraHDR, and JPEG XL. It also includes a new GIF-to-video conversion feature that converts large animated GIFs into MP4 or WebM videos.

Importantly, client-side processing is an opt-in progressive enhancement. Browsers that don’t support required capabilities or devices under 2GB RAM will fall back silently to server-side processing to maintain compatibility and reliability.

The 7.1 iteration refines the initial implementation by improving format support, error handling, upload resilience, and reducing initial bundle size. The wasm-vips and associated WebAssembly modules are loaded on demand during the first upload, minimizing frontend load impact.

To validate these improvements, the WordPress core team urges developers, agencies, and site operators to test a variety of upload scenarios—including different image formats, large files, batch uploads, and feature-specific cases like HEIC photos from iPhones or UltraHDR images—and to report any issues or regressions.

Why This Matters

In production WordPress environments, media uploads are a frequent cause of server load spikes, especially on shared or resource-limited hosting plans. Traditionally, servers handle all image processing, which can consume significant CPU and memory resources during peak upload activity.

By shifting image resizing and encoding to the client, WordPress can reduce server-side bottlenecks. This architectural change brings multiple benefits:

Consistent Image Quality: The wasm-vips library provides uniform resizing and compression across all WordPress sites regardless of hosting stack variations. This eliminates inconsistencies caused by differing server libraries or configurations.
Support for Modern Formats: Native support for AVIF, WebP, HEIC, UltraHDR, and JPEG XL enables WordPress sites to deliver better optimized images with smaller file sizes and improved visual quality, enhancing page speed and SEO.
Reduced Server Load: Offloading CPU-intensive tasks reduces the chance of timeouts or failures during large batch uploads and frees server resources for other critical tasks.
Improved Upload Resilience: The client-side pipeline includes enhanced error handling and fallback mechanisms to maintain reliability in diverse environments.

However, there are trade-offs and ecosystem implications:

Browser and Device Requirements: The feature currently requires Chromium-based browsers and excludes devices with low memory or slow network conditions to avoid degraded experiences.
Increased Client Resource Use: Uploading devices will use more CPU and memory during processing, which could impact battery life and responsiveness on low-end hardware.
Compatibility and CSP Restrictions: Sites enforcing strict Content Security Policies (CSP) may need to adjust worker-src directives to allow blob URLs; otherwise, uploads will fallback to server-side processing.
Operational Testing Need: Since media processing is critical for many workflows, extensive real-world testing is essential to uncover edge cases, performance bottlenecks, and compatibility issues before broad adoption.

What This Means for WordPress Users

For agencies managing multiple client sites, developers building plugins or themes, and hosting customers operating production WordPress environments, this feature signals a significant operational shift in media handling.

Should you care? Absolutely. Media upload performance and reliability directly affect editorial workflows, user experience, and hosting costs. Client-side media processing promises better handling of modern image formats and reduced server resource consumption, which can translate to faster uploads and more scalable hosting setups.

Should you act? Yes. Early testing is crucial. Install the latest Gutenberg plugin in a Chromium-based browser and run comprehensive tests covering:

Uploading diverse image formats (JPEG, WebP, AVIF, HEIC, PNG, GIF)
Uploading large images and batch uploads to evaluate concurrency and progress UI
Testing fallback scenarios on non-Chromium browsers, low-memory devices, or restrictive CSP setups
Validating output formats using the image_editor_output_format filter
Checking animated GIF conversion to video and UltraHDR image processing

Report issues or performance observations to the WordPress core trac tickets (#76756) to help refine the feature before WordPress 7.1 release.

What should you change? Consider adapting image optimization strategies to leverage new modern formats supported natively by WordPress. Ensure your hosting environment and Content Security Policy configurations accommodate client-side processing to maximize benefits. If you operate multi-site or agency environments, test batch and concurrent upload scenarios to anticipate server load shifts. Plugin and theme developers should audit media-related code for compatibility with client-side processing, especially where custom image manipulation or upload hooks are involved.

Frequently Asked Questions

What browsers support client-side media processing in WordPress 7.1?: Currently, support is limited to Chromium-based browsers like Google Chrome, Edge, and Brave due to their support for Document-Isolation-Policy. Firefox and Safari have the feature disabled by default, with limited HEIC canvas fallback support in Safari.
How can I verify if client-side media processing is active on my site?: You can check the browser console for window.__clientSideMediaProcessing (should be true). Network requests to the sideload endpoint during upload also indicate client-side processing. Additionally, a mini plugin exists to label upload processing type on the front end and in the media library list view.
Will client-side processing slow down my site or editor?: The WebAssembly modules load on demand during the first media upload, minimizing initial editor load. Processing happens locally on capable devices, so server load decreases. However, low-memory or slow devices are excluded to avoid degraded experiences.
What happens if my hosting environment has strict Content Security Policy settings?: If your CSP restricts worker-src directives disallowing blob URLs, client-side processing will fallback silently to server-side processing to maintain upload functionality.
Can I customize output formats for uploaded images?: Yes. Developers can use the image_editor_output_format filter to specify output formats such as AVIF, WebP, or JPEG for uploaded images, enhancing optimization workflows.