Direct answer
OpenAI's shopping help page, as accessible on October 28, 2026, says ChatGPT can offer a Try on button on clothing and accessory listings. A user can take or upload a selfie, and ChatGPT Images generates a try-on image. Reference photos can be saved for later use, and products can be saved in Library. For global apparel brands, the discovery surface now extends from title, price and availability into visual consideration, but OpenAI explicitly says the generated image may not represent the product or person exactly and does not guarantee fit or size. Brands should align every purchasable variant's images, color, size system, availability, measurement page and return policy. An OpenAI product feed can provide structured catalog data, but no official documentation says that a field guarantees the Try on button, visibility, ranking or sales.
Facts and background
OpenAI's Shopping with ChatGPT Search help page, as accessible on October 28, 2026, now describes virtual try-on for clothing and accessories. A Try on button may appear on a product listing. The user can take or upload a selfie, and ChatGPT Images creates a try-on image. A user can also upload a picture of clothing or an accessory in a conversation and ask ChatGPT to show how it could look.
The same page says reference photos can be saved in Personalization settings and reused, while products can be bookmarked into Favorites or folders in ChatGPT Library. Product presentation can therefore enter a longer discovery, try-on, save, compare and purchase journey. OpenAI does not document how a merchant qualifies for the Try on button, which countries, brands or catalogs receive it, or any guaranteed relationship between the feature and a product-feed field.
What virtual try-on changes, and what it does not
| Stage | OpenAI documents | A brand can govern | Do not promise |
|---|---|---|---|
| Product discovery | ChatGPT may select products using intent, context, structured metadata and other sources | Authority product pages, structured catalog data, feed freshness and access | Every eligible product will be shown |
| Virtual try-on | Clothing and accessory listings may offer Try on using ChatGPT Images | Variant images, color, material, copy and verifiable detail consistency | A field triggers the button or guarantees eligibility |
| Size decision | Users should verify merchant measurements; generated images do not guarantee fit or size | Size charts, systems, fit notes, measurement methods and market differences | A generated image replaces size guidance or physical fitting |
| Save and compare | Products can be saved to Library and compared through shopping research | Stable identity, durable URLs, current price, stock and policies | A save equals a visit, cart or order |
| Purchase and returns | Users should still check product details, measurements and return policy | Accurate inventory, final price, fulfillment and return facts | ChatGPT information replaces merchant transaction terms |
The critical boundary comes from OpenAI's own notice: a try-on image may not represent the product or the user's appearance exactly and does not guarantee fit or size. It is a generative visualization aid, not garment measurement, body-size inference, product inspection or a service commitment. A brand must not convert “looks suitable” into “will fit” or present the generated image as physical-product evidence.
Give every purchasable variant a stable identity
OpenAI's product-feed specification says that color and size variants should be represented as separate records with distinct item_id values, a shared stable group_id, and selected options in variant_dict. Each row still carries its own price, availability, URL and images. This prevents a black medium listing from using a blue large image, an unavailable size from appearing in stock, or market-specific offers from being merged incorrectly.
| Field or page fact | Governance requirement | Common failure |
|---|---|---|
item_id | Stable and unique for each purchasable color and size combination | Regenerating IDs on every export and breaking continuity |
group_id | Group only variants that are one product on the merchant site | Combining similar styles, different fits or distinct cuts |
variant_dict | Keep option names consistent and aligned with top-level fields and the page | color=Black while the landing state shows white |
| URL and canonical | Restore the selected purchasable option and follow the site's canonical strategy | Sending every variant to a parent page that loses the selection |
| Stock and price | Update per variant rather than copying a parent state to all sizes | One size sells out while the group remains entirely in stock |
Stable identity matters more when a person sees a particular color and silhouette, not an abstract parent product. Even without a published Try on eligibility mechanism, every selected variant should preserve one product truth from the card and image through the detail page and checkout.
Use images to identify the variant, not to promise an outcome
The OpenAI feed requires a primary image for each product record and supports extra views through additional_image_urls. It also says the color value should match the product image. Apparel brands should provide a real primary image for each important color and add front, back, side, material or critical-detail views. Do not reuse an image across variants when it misrepresents color, construction or fit.
Image URLs should remain publicly reachable, return a stable 200 response, use the correct content type and remain durable. Labels, lifestyle staging, model styling and generated backgrounds cannot replace machine-readable facts. Texture, sheen, transparency, included accessories and other visual ambiguities should also appear in visible copy and image descriptions rather than being left for a generative system to infer.
A try-on image is generated by OpenAI for the user's experience. A brand should not republish it as an official product photo, advertising proof or a verified on-body result. Reuse in owned channels would need a separate authorization, labeling, quality and regional-compliance process.
A size label is not a size system, and neither proves fit
The OpenAI feed accepts size and, for integrations configured to carry it, size_system values such as US, UK, EU, JP or CN. OpenAI explicitly says no size-system conversion is inferred when the system is missing. Sending only “S,” “M” or “10” without the market, fit and measurement context is therefore insufficient for a global catalog.
| Layer | Recommended public fact | Acceptance check |
|---|---|---|
| Feed variant | Exact size label, supported size system, stable variant ID and inventory | Sample feed, product page and checkout options together |
| Product page | Body or garment measurements, units, method, fit and stretch notes | Review units and labels by market and language |
| Selection guidance | Model reference data, relaxed or slim fit and category-specific cautions | Confirm every statement comes from verified product facts |
| After-sale boundary | Ill-fitting item handling, exchange, return and final-sale exceptions | Align policy, feed fields and checkout notices |
Visual generation may increase expectations. Inconsistent sizing and policies can then become returns and trust losses. The brand's responsibility is not to make the generated image look more convincing. It is to give the user accurate, verifiable size and risk information after the visual experience attracts attention.
Return acceptance, return window and policy URL are separate facts
The OpenAI feed separates accepts_returns, return_deadline_in_days and return_policy. A policy URL does not imply that returns are accepted, and a return-window value does not enable returns. A final-sale item should use accepts_returns=false, omit the return window and may still link to a policy that explains the restriction.
Global brands should map country, category, promotion, hygiene restrictions and final-sale terms to the actual offer rather than publish one vague worldwide policy. The return window is a duration, not a fixed deadline date. The policy page should explain when the window starts, accepted item condition, shipping responsibility, exchange path and exceptions. OpenAI tells users to verify the return policy, making it decision evidence rather than a secondary legal page.
Keep the feed, public page and shopping surface consistent
OpenAI says approved partners can share product feeds through the Agentic Commerce Protocol and recommends uploading a complete snapshot at least daily. Current values such as price and availability should be updated in the feed when they change. Shopping research may also use public retail pages and other sources. A feed cannot hide an incorrect public page. Product pages, structured data, the feed and checkout should use one product-fact source.
| Fact | Feed | Public product page | Checkout and returns |
|---|---|---|---|
| Variant identity | item_id, group_id, variant_dict | Restorable color and size selection | The same SKU on the order line |
| Visual identity | Primary image and additional views | Gallery and copy matching the selected variant | Order confirmation identifies style and color |
| Price and stock | Current values and promotion state | Visible market price and availability | Final payable amount and actual stock |
| Sizing | Label, variant option and supported system | Measurement chart, unit and fit context | Ordered size and exchange rules |
| Returns | Acceptance, window and policy URL | Accessible complete policy | Execution no weaker than the published promise |
A change in any column should trigger a consistency check. Updating only a site price creates a stale feed. Updating only feed inventory creates a conflict after the click. Replacing an image without checking color metadata separates the visual item from the structured variant.
Measure in layers instead of looking only at orders
OpenAI does not publish merchant-level virtual-try-on impressions, completions or save attribution, and it does not describe how Try on affects product ranking. Brands should not invent a “try-on conversion rate.” Start with owned evidence: feed acceptance and errors, correct product and variant presentation, landing-page consistency, identifiable ChatGPT referrals, size-chart and policy-page engagement, carts and orders, and SKU-level return reasons.
| Measurement layer | Observable evidence | It can establish | It cannot establish |
|---|---|---|---|
| Data admission | Feed validation, update success and crawlable pages | Catalog data can enter processing | Try on or product visibility |
| Presentation accuracy | Product, variant, image, size, price and source URL for fixed questions | Whether one observed result is correct | The same result for every user and market |
| Owned-site behavior | Identifiable referrals, size chart, policy, cart and checkout events | The journey on the merchant's site | Library saves or try-on completions |
| Business result | Orders, margin, return reasons and support questions | Commercial and experience movement | That virtual try-on was the sole cause |
If OpenAI later releases merchant-level try-on or save reporting, add it to a new baseline. Until then, every conclusion should record the platform, market, date, question, product version and observable evidence rather than infer hidden in-product behavior.
Business impact
Virtual try-on moves apparel competition in AI shopping from whether a product is found to whether the visual presentation matches the actual purchasable variant. A global brand that still manages multi-market catalogs with parent-level images, ambiguous size labels and one global return policy may create color, size, stock and after-sale conflicts even when the product is surfaced. Product, content, commerce, local-market and support teams need a shared variant-level fact source. Saving products also extends the information lifecycle. A product saved today may have a different price, stock state or return policy when reopened. Stable IDs, restorable URLs and update cadence therefore affect continuity beyond the first impression. “Still lands correctly after being saved” belongs in product lifecycle governance.
Zhihe Growth assessment
The GEO significance of ChatGPT virtual try-on is not a visual gimmick. Product facts are entering a generative visual interface. The closer that interface moves to purchase, the less images, variants, sizing and return boundaries can depend on ambiguous copy or platform inference. Build a verifiable product knowledge system before optimizing for a new presentation surface. Zhihe Growth recommends a five-layer model: variant identity, visual consistency, sizing context, policy evidence and layered measurement. Align each purchasable variant's ID, image, URL, price and stock first; then add market-specific size charts and return facts; finally test ChatGPT presentation against a fixed product set and owned-site landing states. A feed is a controlled data channel, not a Try on switch. A generated image supports imagination, not proof of fit. A saved product is not a conversion. These boundaries belong in the operating procedure.
Recommended actions
- Inventory apparel and accessory SKUs so every color and size combination has a stable unique item_id and only true variants share a group_id.
- Reconcile variant_dict, top-level color and size, title, URL default selection, price, stock and checkout line item for every sampled variant.
- Provide a truthful primary image and necessary front, back, side and detail views for major colors; remove cross-variant reuse that misstates color, material or construction.
- Publish market-specific size charts, units, measurement methods, fit and stretch notes; use size_system only after confirming the integration supports it and never assume conversion.
- Maintain accepts_returns, return_deadline_in_days and return_policy separately and map country, category and final-sale exceptions to the actual offer.
- Use one product-fact source across the product page, Product structured data, OpenAI feed and checkout, with checks for price, stock, image and policy changes.
- Keep primary images, additional views, product pages, size charts and return-policy URLs public, stable and readable on mobile without login.
- Run fixed-product and fixed-question tests that record the surfaced product, exact variant, image, price, source URL, date, market and account state.
- Record feed processing, ChatGPT presentation, owned-site referrals, carts, orders and return reasons separately; do not create an unsupported try-on conversion metric.
- Review broken images, unavailable variants, size conflicts, stale prices and policy drift monthly, repairing source data, feed and public page together.
Limitations
This article is based on OpenAI help and developer documentation accessible on October 28, 2026. The shopping help page shows a recent update and describes virtual try-on, reference photos and Library saves. It does not provide a field-level changelog, so this article does not infer an exact rollout date, supported-country list, merchant eligibility algorithm or universal account availability. OpenAI does not say that any image, color, size, feed or structured-data field triggers the Try on button. Product-feed onboarding is currently available to approved partners. A field being accepted, a page being crawlable or a product appearing once does not guarantee virtual try-on, ranking, saves, clicks, checkout or sales. Shopify catalog integration and direct-feed onboarding are also distinct operating paths. A virtual try-on image may not represent the product or person exactly and does not guarantee fit or size. It cannot replace real product imagery, measurement charts, quality evidence, local consumer information duties or return commitments. This article is not legal advice. Brands should separately review regional requirements for generated imagery, user photos, advertising reuse, sizing claims and return terms.