Since WordPress 7.1, images you upload in the block editor are no longer resized by PHP on your server. The browser does it, using a WebAssembly build of libvips, and then sends every sub-size back to WordPress over the REST API.
That is great for cheap hosting. It is not great if you run an image optimizer, an S3 offload plugin or a resize plugin that expects the old server-side upload path. Those plugins can miss editor uploads completely, process the same image twice, or get 400 errors from the new sideload route.
Below is how to check if the feature is active on your site, how to turn it off with one filter, and how to keep it on without breaking things.
What changed in the upload flow
According to the official Client-Side Media Processing guide, an upload from the editor now takes three kinds of REST requests instead of one:
POST /wp/v2/mediacreates the attachment.POST /wp/v2/media/{id}/sideloadruns once for every generated sub-size.POST /wp/v2/media/{id}/finalizerunswp_generate_attachment_metadatawith theupdatecontext.
The part that bites plugins: on this path, wp_image_editors, image_make_intermediate_size and image_memory_limit never fire. If your optimizer or resize plugin hooks into those, it simply does not run for editor uploads anymore.
Some hooks still work. big_image_size_threshold, image_editor_output_format, wp_editor_set_quality and jpeg_quality are passed to the browser, and wp_handle_upload fires for each sideloaded sub-size.
Plugin authors have already reacted. The BU Media S3 plugin turns the feature off because it generates sizes on demand and browser-made sizes bypass that. Smart Image Upload Resizer unregisters the sideload and finalize routes, because core rejects a sideload with a 400 when a server-side resize makes the dimensions disagree with the stored metadata.
Check if your browser is using it
The feature only kicks in when every requirement is met. If one fails, WordPress silently falls back to server-side processing. As of 2026-11-01 the guide lists:
- Chrome 137+ or Edge 137+ (Firefox and Safari are not supported for the WebAssembly pipeline)
- WebAssembly, SharedArrayBuffer, Web Workers, and a Content Security Policy that allows
blob:workers - More than 2 GB of device memory and at least 2 CPU cores
- A connection that is not
2gorslow-2g, with Save-Data off
Open a post in the block editor in Chrome, open DevTools (F12), and run this in the Console:
console.log( window.crossOriginIsolated );You should see true when the editor is cross-origin isolated, which the browser pipeline needs. Then upload an image to an Image block and watch the Network tab: requests to /sideload and /finalize mean the browser did the work.
Turn client-side processing off with a must-use plugin
Core gives you one switch: the wp_client_side_media_processing_enabled filter. I put it in a must-use plugin rather than the theme’s functions.php, so it survives theme switches and cannot be deactivated by accident.
Step 1. Create the mu-plugins folder
Back up your site first. Then, from the WordPress root over SSH:
mkdir -p wp-content/mu-plugins
nano wp-content/mu-plugins/disable-client-side-media.phpStep 2. Add the filter
<?php
/**
* Plugin Name: Disable client-side media processing
* Description: Send block editor image uploads back to server-side processing.
*/
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Save the file. It loads on the next request, and you should see it under Plugins > Must-Use. On WordPress versions before 7.1 the filter does not exist, so the file does nothing there and is safe to leave in place.
Step 3. Confirm uploads go through PHP again
Reload the editor, upload an image, and check the Network tab. You should only see the single POST /wp/v2/media request, with no /sideload calls after it. Your optimizer or offload plugin should process the file as it did before 7.1.
💡 If you only want the old behavior for some users, return false from a callback instead of __return_false, for example when ! current_user_can( 'manage_options' ). The official guide shows this pattern.
Know the trade-off before you disable it
Switching it off is not free. There is an open Gutenberg issue, #84718, where the editor’s uploadMedia() sends every file at once instead of one by one.
With client-side processing on in Chrome 137+, uploads are capped at 5. On the fallback path (Firefox, Safari, non-HTTPS sites, and sites that disabled the feature) nothing caps them, so dropping a dozen photos into a Gallery block makes PHP resize them all in parallel.
On small plans that means slow uploads, host rate limiting, blank thumbnails, or the familiar not a valid JSON response error. As of 2026-11-01 a fix is in review and on the WordPress 7.2 task board. WordPress 7.2 is planned for December 8.
Until that ships, if you disable the feature, upload big batches in smaller groups. And if your host gives you few PHP workers, that is one more reason to keep the browser pipeline on and fix the plugin conflict instead.
Keep it on without breaking other things
If nothing on your site depends on the server-side image hooks, I would leave the feature on. Two things commonly make it fall back or misbehave.
A strict Content Security Policy. The image worker runs from a blob: URL. If your CSP has a worker-src directive (or no worker-src but a strict script-src, which workers fall back to), add blob: to it. In nginx that looks like this:
add_header Content-Security-Policy "worker-src 'self' blob:;" always;💡 If you already send a CSP header, add blob: to the existing policy instead of adding a second header. Browsers enforce every CSP header they get, so the old one would still block the worker.
Cross-origin resources that need a login. To get SharedArrayBuffer, WordPress isolates block editor screens with the Document-Isolation-Policy header in isolate-and-credentialless mode. Cross-origin resources then load without cookies, so anything in the editor that needs a signed cookie or a logged-in session on another domain can break. Most page builders are not affected, because DIP is skipped on admin pages whose action is anything other than edit.
For plugin developers, the fix is to move work to hooks that still run. Check the attachment in wp_generate_attachment_metadata, which fires again on finalize, or handle files in wp_handle_upload, which fires for every sideloaded size. Pass resize limits through big_image_size_threshold so the browser respects them instead of fighting them.
Keep an eye on the next release. In 7.1, client-side processing only covers uploads inside the block editor, not Media > Add New. Beta coverage of 7.2 says the same approach is coming to the Media Library, so a plugin that only works today because people upload through the Media Library will meet the same problem in December.
If the editor itself acts up on 7.1, see my post on the blank Site Editor and Promise.withResolvers. And if you are not sure where to put PHP snippets like the one above, read how to execute PHP code on your WordPress website.
TL;DR: WordPress 7.1 resizes block editor uploads in the browser, which bypasses image_make_intermediate_size and friends. If your image or offload plugin broke, drop add_filter( 'wp_client_side_media_processing_enabled', '__return_false' ); into a must-use plugin. Upload in smaller batches until the parallel upload bug is fixed, and allow blob: workers in your CSP if you keep the feature on.
