Practical guide · written against WordPress 7.1-RC3, August 2026
The short version
- Your images may now be processed in the browser. WordPress 7.1 can resize, compress, rotate and convert an image, and build every thumbnail, using WebAssembly in the visitor's browser. Only the finished files are uploaded.
- That is a risk for anything written inside the file. A badge on the page is safe. An IPTC or C2PA mark embedded in the image is only as durable as the last program to re-encode it.
- AIM already handles it, and we checked against the release candidate rather than assuming. The mark reaches the original and every resized copy through the new two-stage upload. No update is needed and you do not have to do anything.
What actually changed
Until now, uploading an image meant sending one big file to your server and letting PHP do the work: rotate it, shrink it, and cut the handful of sizes your theme asks for. WordPress 7.1 can move that work into the browser using wasm-vips, a WebAssembly build of the libvips image library. The browser does the resizing, then uploads each finished size on its own.
The upside is real. Large photos stop being a server problem, uploads feel faster, and hosts with tight memory limits stop failing on big files.
The catch is what happens to everything that is not pixels. When a program decodes an image and writes a new one, the metadata inside it only survives if that program deliberately carries it across. Camera settings, copyright fields, and the AI provenance marks this plugin exists to write are all in that category.
Who this affects, and when
Less broadly than the headline suggests, which is worth knowing before you worry about it. From testing against the release candidate:
- It applies to uploads made in the block editor. Adding a file through the Media Library screen still goes to your server the old way.
- It needs a secure context, so an HTTPS site or local development. That is most real sites.
- It needs the browser to grant a capability called
SharedArrayBuffer, which requires an isolation header. WordPress sends one, but only to Chromium 137 and newer. Firefox and Safari never receive it, so uploads made in those browsers keep going to your server. - It steps aside for page builders. When a plugin takes over editing with its own screen, WordPress skips the header rather than break the editor that relies on reaching inside its own iframe.
Put together, this is far less all-or-nothing than the announcement sounds. The same site can process one upload in the browser and the next one on the server, decided by nothing more than which browser the author happened to open. You do not pick the path, and you cannot tell from the finished post which one ran.
Why this matters for disclosure
AIM writes an AI disclosure in three places on purpose: a badge your readers see, a machine-readable record on the page, and the IPTC DigitalSourceType value inside the image file itself. The third one is the reason a label still means something after somebody downloads your image and posts it elsewhere.
Embedded metadata has never been permanent. Image optimizers strip it. CDNs strip it on re-encode. Screenshots destroy it entirely. Client-side processing simply adds one more place it can be lost, and moves that place earlier: before the file has ever reached you.
This is exactly why the disclosure is not kept in one place. If the embedded mark is lost, the visible badge and the page record are untouched, and your disclosure obligation is still met. The embedded copy is what makes the claim travel; it is not what makes you compliant.
What we tested
We installed WordPress 7.1-RC3 and put the plugin through real uploads rather than reasoning about it from the release notes. One thing to be straight about first: we could not get a browser to hand us the client-side path on demand, because it needs a capability the browser grants on its own terms. So the upload behaviour below is measured, and the description of when 7.1 makes its two announcements is read out of core rather than watched happening. We would rather mark that line than blur it.
The thing worth knowing is in the timing. When the browser handles processing, WordPress no longer announces an image as finished once. It says so twice: first when the upload arrives, and again once the resized copies have been sent up individually. The second announcement is the one that carries the resized copies, so a plugin that acts only on the first will mark the original and miss every thumbnail.
That is a real trap, and it catches anything written to treat the two announcements differently. It did not catch us, because AIM never distinguished between them: it does the same work every time it is told an image is finished, and re-marking a file that already carries the right value costs nothing, so the second pass simply completes what the first could not. We checked rather than assumed. On a test upload carrying its own declared provenance, the mark came out present in the served file and every generated size, with the declared value correctly recognised and adopted. How many sizes that is depends on your theme and plugins, so the check is that none are skipped, not that the count matches ours.
With one exception worth knowing about. When you upload something large, WordPress scales it down for use on the site and quietly keeps your untouched original alongside it. AIM marks the file your site serves and every size cut from it; it does not write into that pristine original. So on a big upload the count is every file but one. Nothing you publish is unmarked, and nothing about 7.1 changed this, but if you hand people the original file straight off the server it will not be carrying the embedded mark.
We then did the part that is easy to skip, and put the previously released version through the same test, because a fix you did not need is worth knowing about too. It behaved identically. Nothing had to change. We would rather say that plainly than describe a repair we did not have to make.
Both plugins were tested, not just the free one. Pro adds automatic flagging, which reads provenance out of a file the moment it is uploaded, so it listens on the same signal. On 7.1 it recognised a declared value on arrival, applied the label without anybody touching it, and did not flag the image a second time when the second announcement came. Pro is server-side from end to end, with no editor JavaScript of any kind, so the new iframed editor has nothing of Pro's to break.
We also confirmed the parts that were never at risk: both plugins load cleanly on 7.1, every REST route still answers, nothing writes a deprecation notice into the log, the editor panels are unaffected by the iframed editor because they live in the sidebar, and nothing anywhere touches jQuery UI or the editor toolbar.
The risk that is actually worth your attention
It is not the one the headline suggests. While testing we kept looking for wasm-vips quietly discarding metadata, and found the more mundane problem sitting next to it.
7.1’s browser path does not only resize. It can convert, and conversion is on by default, which is how a JPEG you uploaded becomes a WebP on the way in. That is good for your visitors. It used to matter here because writing provenance into WebP, AVIF, GIF and TIFF needed exiftool on the server. Since 2.2.0 it does not. AIM writes every format itself, in plain PHP, on any host.
The failure this section described, an ordinary shared host with no exiftool quietly converting uploads to WebP, no longer applies. Before 2.2.0 the badge and the page record are unaffected and your disclosure obligation is still met, but the mark that travels with the file is simply not there.
The plugin never hid this. The Metadata screen named the formats it could not write into on your server rather than reporting a score it had not earned. From 2.2.0 there are none to name: the per-format breakdown is coverage, not a list of things your host cannot do.
What you should do
Nothing, which is the useful answer. If you are on a current version of AIM you are already covered on 7.1, including the version that was live before 7.1 shipped. There is no urgent update, and we would rather tell you that than manufacture one.
If you work with images that arrive already carrying provenance, from a camera, a picture library or an asset manager, and you want to be certain nothing is re-encoded before it reaches you, you can switch the browser path off with a single filter:
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Use that sparingly. It gives up a genuine performance improvement to solve a problem you may not have, so it is worth confirming you actually lose metadata before reaching for it. The plugin's Metadata screen gives you one row per image format, showing how many of your marked images actually carry the embedded value, which is the quickest way to check your own site rather than take anybody's word for it.
The wider point
Provenance standards assume a file keeps its metadata. The web keeps proving that images get re-encoded constantly, by optimizers, by CDNs, by social platforms, and now by the browser before an upload finishes. Any disclosure strategy that depends on a single embedded value is one re-encode away from silence.
That is the argument for layering, and it is the reason this plugin has always written three marks instead of one.
Related guides
The lawThe EU AI Act and WordPress (Article 50)
Who Article 50 covers, the 2 August 2026 deadline, the penalties, and exactly what a WordPress site owner must do, in plain English.
Read guide
The how-toHow to label AI images in WordPress
A step-by-step walkthrough: install the plugin, flag an image from the Media Library, and get the badge, embedded metadata and JSON-LD automatically.
Read guide
The metadataWhat IPTC DigitalSourceType actually is
The machine-readable tag behind “AI-generated”: what the IPTC DigitalSourceType vocabulary means, the values AIM Transparency writes for AI and human provenance alike, and why it future-proofs your images.
The shopDisclose AI product images in WooCommerce.
Selling with AI product photos? Put the “AI Generated” badge across your shop grid, your categories and the single-product gallery, free, plus embedded provenance, on any theme. Compliance and buyer trust, in one move.
Read guide
Written textHow to disclose AI-written text in WordPress
The half of Article 50(4) nobody quotes. Whether the text duty reaches your site at all, how to record it per post, and why human review on its own is not the exemption.
Read guide
ChatbotsHow to disclose an AI chatbot on WordPress
Article 50(1) is the other half of the law: if visitors interact with an AI, you have to tell them. Where the notice belongs, and how to find widgets already running.
Read guide
LanguagesYour AI disclosure has to be in a language visitors read
Article 50 asks you to inform the person. An English badge on a Polish shop does not. How disclosure works across 22 EU languages, and where the wording comes from.
Read guide
For developersShow an AI disclosure automatically with WordPress hooks
One filter, one condition, one call to do_shortcode. Copy-paste recipes for categories, custom fields, WooCommerce and block themes.
Read guide