A product photo is usually several files. The same shot exists as a large JPEG, a smaller WebP and an AVIF for browsers that support it. A product video has an MP4, a WebM and a streaming manifest. A 3D model ships as GLB for Android and USDZ for iPhone. Until last week, the Universal Commerce Protocol had no way to say so.

On 29 September the UCP maintainers merged PR #690, from Shopify's Ilya Grigorik, which rebuilds the Media type that products and variants use for images, video and 3D models. This post covers what changed, what it means for the agents and the stores on each side, and what stores send in that field today.

#What is UCP product media?

media is the list of images, videos and models attached to a product or a variant in UCP's catalog capability. An agent gets it back from catalog search and lookup, and uses it to show the buyer what they're about to buy. It is an ordered array: the business puts the most relevant item first, and the platform treats the first item it shows as the featured one.

In the released version, v2026-08-25, each item has five fields: type, url, alt_text, width and height. Only type and url are required. type already listed video and model_3d as well-known values, so a business could point at a video file. What it couldn't do was describe one.

#Why one URL wasn't enough

One URL and one pair of dimensions describe one file. The PR lists what that leaves out:

• Alternate encodings and sizes of an image. A responsive storefront picks AVIF, WebP or JPEG and a width to suit the screen. An agent with a single URL gets whatever the store chose.
• Video renditions and streaming manifests. There was nowhere to put the 1080p and 480p versions, or an HLS or DASH manifest that adapts to the connection.
• Device-specific 3D formats. GLB and USDZ are the same model for different devices.
• A poster still, so an agent can show something before a video or model loads, or instead of it.
• A video that only exists inside a third-party player, such as a review hosted on a video platform.

A business could list several items, but then the agent sees several pictures, not several versions of one picture.

#What #690 adds

The change keeps one Media schema and extends it, following schema.org's MediaObject family. Every new field is optional.

Each of the four well-known types (image, video, external_video, model_3d) now has its own short schema that says what url and sources mean for that type. For an image, url should be the most widely supported rendition, because a platform that ignores sources loads url directly. For a video, url is a playable file or a streaming manifest. For a 3D model, it's the primary model file, such as GLB.

Here is the merged example of an image with two encodings:

{
  "type": "image",
  "url": "https://cdn.example.com/products/runner-pro-blue.jpg",
  "alt_text": "Runner Pro in Blue",
  "width": 1600,
  "height": 1600,
  "sources": [
    { "url": "https://cdn.example.com/products/runner-pro-blue.avif", "mime_type": "image/avif", "width": 1600, "height": 1600 },
    { "url": "https://cdn.example.com/products/runner-pro-blue.jpg", "mime_type": "image/jpeg", "width": 1600, "height": 1600 }
  ]
}

And a 3D model with a poster and two formats:

{
  "type": "model_3d",
  "url": "https://cdn.example.com/product.glb",
  "preview": { "url": "https://cdn.example.com/product-poster.jpg" },
  "sources": [
    { "url": "https://cdn.example.com/product.glb", "mime_type": "model/gltf-binary" },
    { "url": "https://cdn.example.com/product.usdz", "mime_type": "model/vnd.usdz+zip" }
  ]
}

filesize is there for exactly the 3D case: it lets an agent decide whether to fetch a multi-megabyte model before the buyer asks to see it.

#The rules for agents

The PR adds a short list of platform rules alongside the fields:

• Unknown types don't break anything. A platform must not reject a product or a response because it doesn't recognise a media type. It may show the item from preview and name, or leave it out. The same goes for an unknown mime_type or format on a source: the platform may skip that source, but must not reject the item.
• Pick from sources by type and size. A platform chooses a rendition by mime_type and dimensions. A business that lists sources should include the file at url among them.
• HTTPS is allowed to matter. A platform may refuse to load or embed a media URL that isn't https.
• External players are isolated. A platform that embeds an external_video player must keep it away from the platform's own authority: no platform credentials, no access to platform APIs or agent tools, no protocol messages, no navigating the host app. Before embedding, it must decline the item unless url is an absolute https URL, without user info, on a different site from the platform. On the web, the spec illustrates this as one sandboxed, credentialless iframe.

That last rule is the one with security weight. An agent that drops a store-supplied player into its own interface is running someone else's code next to the buyer's session, and the spec now says what it must hold back when it does.

#Does it break existing integrations?

No. The PR is written to be additive for anyone already using the released shape. The required fields are still type and url. Nothing is removed, renamed or retyped. url, width and height keep their meaning, and unknown type values stay valid.

One stronger rule was deliberately held back. An earlier revision rejected non-https media URLs in the schema. In review, Grigorik walked that back to "a platform may refuse", because he wants the change usable on 2026-08-25 rather than waiting for the next release, and requiring https would break that. A protocol-wide https requirement for every URL a platform renders, links or embeds is to be proposed separately.

As of 5 October, #690 is on the spec's main branch and in the draft docs. It hasn't been backported to the 2026-08-25 release branch yet. Because the fields are optional and old readers ignore them, a business can start sending them without breaking an agent that doesn't understand them yet.

#What stores send in media today

We looked at live catalog replies from a dozen large Shopify stores on 5 October. Ten answered, giving 92 products from catalog search and five lookups.

• Every product came back with exactly one media item, of type image.
• None had width, height, sources or preview. Search results on seven of the ten stores included alt_text. The lookups had none.
• Variants carried one image each too, which is what lets an agent show the blue shoe when the buyer picks blue.
• The same stores' own public product data carried between 3 and 70 images per product. On one store, 4 of the 10 products we looked at had a video on the store's own product page.

So the rich media exists. Today's catalog replies send close to the minimum the schema asks for. That's a choice made once per platform rather than per store: on a hosted platform, the platform's UCP server decides what goes into media for every store on it. The new fields give those servers a standard place to put the rest.

This was a small, dated sample on one platform, not a census. We'll watch the field across the crawl and report when sources, preview or a non-image type first shows up in live replies.

#What's next

• Media on option values. PR #675, opened in August, proposes an optional media on option values, reusing the same type. Its main use is a colour swatch for a Color option. It's still open, with no reviews yet.
• A backport to 2026-08-25, if the maintainers follow through on putting this in the current release.
• The https sweep across every URL a platform renders.
• Bulk feeds. The feed capability draft from the Bulk Product Discovery working group publishes the same Product records that search returns as files, so the media on those records, new fields included, would travel in feeds too.

#FAQ

Can UCP products include video? Yes. video was already a well-known type in the released version. Since #690, a video item can also carry renditions and streaming manifests in sources, a poster in preview, a name and a duration. A video hosted in a third-party player uses type: external_video.

Does UCP support 3D models? Yes, as type: model_3d. url is the main model file, such as GLB, and sources lists other formats such as glTF and USDZ, with an optional filesize for each.

Do I have to change my UCP server? No. Every new field is optional and the change is additive. If your platform or server sends one image per product, it stays valid.

What happens if an agent doesn't recognise a media type? It must not reject the product. It can show the item's preview and name, or skip it.

Is this in a released version of UCP? Not yet. It's merged to the main branch and in the draft docs. It isn't in v2026-08-25 as of 5 October.

#Check your catalog

Our catalog validator checks whether every product in a catalog reply has media, and whether each media item has the required type and url. If you're adding video or 3D to your UCP responses, run your replies through it to see what an agent gets back.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• PR #690: model image, video, external video, and 3D variants, merged 29 September 2026
• Catalog capability (draft docs), Media section, ucp.dev
• Media schema on main
• UCP release v2026-08-25
• PR #675: add optional media to option_value (open)
• PR #866: feed capability for bulk catalog access (draft)
• schema.org MediaObject
• UCP Checker live sample of catalog search and lookup replies, 5 October 2026

Related coverage: UCP's first Domain Working Group starts with product feeds · Shopify's Storefront MCP after August 31 · Catalog validator · UCP for Retail