Intent to Experiment: User Agent Image Replacement API

[Chromestatus]

Contact emails

jbr...@chromium.org

Explainer

https://github.com/explainers-by-googlers/ua-image-replacement

Specification

https://github.com/explainers-by-googlers/ua-image-replacement

Summary

Modern browsers can provide capabilities to augment the browsing experience by modifying media in the page on behalf of the user. The advent of generative AI makes it more likely that browsers will add such features. Sometimes, the replacement content added at the user request might not match other content and functionality in the page, which could confuse the user. Even if this cannot be completely avoided, if authors can observe when replacement happens they can adjust the document to mitigate confusion (e.g., by hiding or adjusting other content). For example, a user browsing an e-commerce site with a generic product image (e.g., a model wearing a jacket) might wish to imagine themselves wearing the item. The user agent uses generative AI technology to produce that image and present it in place of the model image. The page improves the user experience by removing text referring to the model's dimensions and the garment size depicted, as it may not be correct in the replacement image.

Blink component

Blink>Image

Web Feature ID

Missing feature

TAG review

none as yet (API shape is trivial, API owner discretion needed on whether this requires review)

TAG review status

Pending

Goals for experimentation

We're looking on hearing from sites which are affected by Chrome features allow users to generate and emplace edited images in web pages, about whether this API allows them the information required to optimize the user experience as these features are used. If additional or different API is required to adapt appropriately, we'd like to know that sooner rather than later, especially if the changes required are not purely additive.

Origin Trial documentation link

https://github.com/explainers-by-googlers/ua-image-replacement

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Ongoing technical constraints

None

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

No

Flag name on about://flags

No information provided

Finch feature name

No information provided

Non-finch justification

No information provided

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/544822216

Launch bug

https://launch.corp.google.com/4452457

Estimated milestones

Origin trial desktop first	152
Origin trial desktop last	157

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5076374013476864?gate=5435940823760896

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Hey Jeremy,

Thanks for filing this. Would be good to see this sent to the TAG, as I'm not sure it qualifies as trivial.

On the overall feature, Edge has some experience with features in this space, as we had some image and video "superresolution" features that we have since un-launched. A couple of thing we learned along the way:

• It's extremely important for developers to have control. Consider radiology charts or other regulated enviornments. We cannot be messing with images in those settings, and so there have to be controls (and I'd argue, affirmative developer opt-in) to gate this sort of feature. The I2E implicitly fits this, but it isn't clear from the explainer that it will remain opt-in.
• Developers will need visibility in logging for impacts on latency and potential control over replacement UI. E.g. if this snaps in later than the original image, do we have good CSS controls for making sure the transition is seamless? (I know the answer to this question, which is "no", but it should be addressed in any Explainer).
• Given that this is a feature that uses LLMs behind the scenes, has thought gone into interop?

Best,

Alex

[Jeremy Roman]

Thanks for the feedback and advice; responses inline.

On Wed, Aug 12, 2026 at 11:55 AM Alex Russell <sligh...@chromium.org> wrote:

Hey Jeremy,

Thanks for filing this. Would be good to see this sent to the TAG, as I'm not sure it qualifies as trivial.

This is thin enough that I'm not quite sure what feedback I would be asking for TAG's time on.

With respect to form, certainly we could imagine different naming, or some enum or dictionary instead of a boolean, or something like that. It's quite a small API surface, though, and I don't think anything is very out of the ordinary.

With respect to function, most of the interesting functionality (what sorts of transformations the user might do, what capabilities the user has to control it, how associated user data is stored and processed, etc) resides in vendor-specific features that are for the moment outside the scope of standardization. Maybe in the future some of these capabilities will be useful to expose to the platform and at that time much deeper standardization discussion would be beneficial. The only functionality added to the platform here is that some web pages can tell that some sort of browser feature was used in a way that might change the content the user sees.

To me it seems that the size of the platform exposure in both respects is rather modest, but if others would like this reviewed I'm not necessarily opposed.

On the overall feature, Edge has some experience with features in this space, as we had some image and video "superresolution" features that we have since un-launched. A couple of thing we learned along the way:

• It's extremely important for developers to have control. Consider radiology charts or other regulated enviornments. We cannot be messing with images in those settings, and so there have to be controls (and I'd argue, affirmative developer opt-in) to gate this sort of feature. The I2E implicitly fits this, but it isn't clear from the explainer that it will remain opt-in.

For the first Chrome feature I'm looking at surfacing this way, we'll probably avoid this particular concern, because it applies only to certain kinds of images and we only perform the transformation when the user explicitly uses the feature from browser UI.

This API is very generic; it simply lets pages know when some such feature has touched their images. It could conceivably be used for features which should have additional controls of the form you mention, but I'm not sure what can be done at this level to address that beyond advice that browser vendors consider this potential issue with each such feature they implement. I'm fine to do that if it's helpful, though in many cases it'll refer to browser features which standards don't generally describe.

• Developers will need visibility in logging for impacts on latency and potential control over replacement UI. E.g. if this snaps in later than the original image, do we have good CSS controls for making sure the transition is seamless? (I know the answer to this question, which is "no", but it should be addressed in any Explainer).

One application of this API is identifying when image replacement features are (or have been) in use, so that developers can consider that when looking at performance reports. Given the transformations and how they are presented is within the purview of the vendor-specific feature, I'm not sure how much there is to say here. Features that happen on page load might want controls analogous to CSS font-display (I assume this is what you're referring to), but this doesn't really apply to features that transform images much later based on user action.

I can explicitly state that this is out of scope (for now) if you think it's helpful.

• Given that this is a feature that uses LLMs behind the scenes, has thought gone into interop?

At this time I'm not pursuing interoperability on the particular generated outputs (or indeed on the types of transformation at all), though that could happen in the future.

Nonetheless it does seem useful to work toward interoperability in the following sense: if website www.photographyblog.com wants to remove a label that says "this photo was taken by a human on 01/02/2016" when the image is substantively transformed in Chrome, then when another browser adds a similar (or even cooler) transformation feature it should be able to benefit from this behavior in that site (and any other site).

[Sangwhan Moon]

Adding a couple of drive-by questions below, 

On Wed, Aug 12, 2026 at 5:14 PM Jeremy Roman <jbr...@chromium.org> wrote:

Thanks for the feedback and advice; responses inline.

On Wed, Aug 12, 2026 at 11:55 AM Alex Russell <sligh...@chromium.org> wrote:

Hey Jeremy,

Thanks for filing this. Would be good to see this sent to the TAG, as I'm not sure it qualifies as trivial.

This is thin enough that I'm not quite sure what feedback I would be asking for TAG's time on.

With respect to form, certainly we could imagine different naming, or some enum or dictionary instead of a boolean, or something like that. It's quite a small API surface, though, and I don't think anything is very out of the ordinary.

With respect to function, most of the interesting functionality (what sorts of transformations the user might do, what capabilities the user has to control it, how associated user data is stored and processed, etc) resides in vendor-specific features that are for the moment outside the scope of standardization. Maybe in the future some of these capabilities will be useful to expose to the platform and at that time much deeper standardization discussion would be beneficial. The only functionality added to the platform here is that some web pages can tell that some sort of browser feature was used in a way that might change the content the user sees.

To me it seems that the size of the platform exposure in both respects is rather modest, but if others would like this reviewed I'm not necessarily opposed.

On the overall feature, Edge has some experience with features in this space, as we had some image and video "superresolution" features that we have since un-launched. A couple of thing we learned along the way:

• It's extremely important for developers to have control. Consider radiology charts or other regulated enviornments. We cannot be messing with images in those settings, and so there have to be controls (and I'd argue, affirmative developer opt-in) to gate this sort of feature. The I2E implicitly fits this, but it isn't clear from the explainer that it will remain opt-in.

For the first Chrome feature I'm looking at surfacing this way, we'll probably avoid this particular concern, because it applies only to certain kinds of images and we only perform the transformation when the user explicitly uses the feature from browser UI.

1. Extending Alex's developer control question: does this mean the proposal considers preventDefault() against the uareplacestart event a no-op?

2. Skimming the explainer, my understanding is that when blitting the "transformed" image to an HTMLCanvasElement or serializing it, the expectation is that it will be a reference to the original image, correct?

3. If the expectation for (2) is to make the replaced image transparent, how do you see this working with getDisplayMedia()? (I ask because this might not be trivial)

4. Extension of developer control: Was a site-initiated HTMLImageElement.requestReplaceImage() path (e.g. gated by a user gesture) considered?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13eUhYfhQg1r6-13O77Ui2OiL2cszWZL_vDum-42GzR8rA%40mail.gmail.com.