Open the post editor console on a site running the latest Gutenberg plugin and type one line:
window.__clientSideMediaProcessing
// true means the browser, not PHP, resized your last uploadIf it comes back true, the browser, not PHP, built your thumbnails. Client-side media processing decodes, resizes, and re-encodes every sub-size in a WebAssembly build of libvips before anything reaches your server, which then just stores the result. The worker is fetched on demand the first time someone uploads media and isn’t part of the editor’s initial bundle. The feature graduated from a Gutenberg experiment during the 7.0 cycle, and I wrote about that groundwork when it was still an experiment. It is now targeting WordPress 7.1 as a core capability, which is why Adam Silverstein opened a call for testing on Make WordPress Core.
Where client-side media processing runs
Firefox and Safari are off entirely because they don’t support Document-Isolation-Policy, which the processing worker relies on. Devices reporting 2 GB of RAM or less are excluded, and so are 2g and slow-2g connections and browsers sending the Save-Data header, because the worker download is heavy. Sites whose CSP worker-src directive doesn’t allow blob: fall back as well.
A commenter on the post added a detail the list leaves out: on iOS every browser is WebKit, so Chrome on an iPhone takes the server path like Safari does. In practice this is a Chromium desktop and Android feature. That’s fine for a progressive enhancement, but plan your QA around that rather than the pitch. The HEIC-from-iPhone test only works when you upload from a computer, since iOS converts HEIC to JPEG before the file leaves the phone.
When a gate fails, the user sees nothing. The upload runs the old server path and the only trace is a message in the developer console. That’s the feature working as designed, and it’s also how you end up with bug reports you can’t reproduce.
What this means for media plugin code
If you maintain anything that touches images on upload (an optimizer, a watermark, a WebP converter wired to image_editor_output_format, an offload plugin), your code runs in PHP. When client-side media processing is active, the browser has already produced the sub-sizes before PHP sees the file, so the hooks you rely on either receive different input or never run. The testing post asks media plugin maintainers to run their plugins against the feature and report gaps, and there are new filters and actions in the tracking PR. I wouldn’t assume your quality or format settings survive the trip until someone has checked.
The tempting move is to wait for 7.1 and see. That fails quietly. Staging is usually Chrome on a decent machine, your client may well be on Safari, and the same upload will behave differently in each with nothing in the UI to explain why.
So make the path visible. The post links a small helper plugin that shows a client or server label on the front end and adds a column to the Media library list view. Install it, then run the output format test from the post:
<?php
add_filter( 'image_editor_output_format', function ( $formats ) {
$formats['image/jpeg'] = 'image/webp';
return $formats;
} );Upload one large JPEG in Chrome, then the same file in Firefox, and compare what lands in the uploads directory: names, formats, the -scaled variant, file sizes. The media library still runs the server pipeline, so it gives you a baseline for free, and I wrote about what that editor touches and what it leaves alone if you want the background. If the WebP sub-sizes appear on both paths, your format configuration carried over. If they only appear on the server path, you found a gap, and it belongs on the tracking issue tagged [Feature: Client Side Media].
If you ship a media plugin, or look after stores where the image pipeline is load-bearing, I’m happy to run this test round against your setup and write up what breaks before your users do.
The savings on the server side are real. Decoding and re-encoding are the expensive part of an upload, and shared hosting is where big originals die in PHP timeouts, so handing that work to the client’s machine is a good trade when the machine can handle it. I still don’t know how offload plugins that write straight to object storage interact with the sideload path, and that is the first thing I’d test.
Do this today on a staging copy of one site you care about: install the latest Gutenberg, type the console line in the post editor, upload one 5 MB JPEG, then list the uploads folder and count the files. Ten minutes tells you whether 7.1 splits your image pipeline in two or just adds a column you never look at.
