Size charts AI shoppers can read: data, not images

Short answer: an assistant can only turn “my head measures 56 cm” into “order the M” if it can read your chart as rows, and no storefront surface returns a chart that is an image, a PDF, a pop-up page or a metafield. Store the chart as structured rows (size, minimum, maximum, unit), link it from each product, and give agents a tool that reads it.

The question your staff answer every day

“I measure 56 cm around the head, which size?” “My foot is 27.5 cm, is that a 43 or a 44?” “Chest 98 cm, medium or large?” A shop assistant answers with the chart. A shopper on your site finds the chart, reads the row, and checks that size is in stock.

An AI shopper has to do the same three things, and the second is where it fails. In our batch of 340 shopper questions across 34 specialist Shopify storefronts on 4 September 2026 (one shopper model, OpenAI’s GPT-5.4 mini via the API, native storefront tools only, in a simulated check), 119 of the 186 answers that were not fully right failed on a single fact about a single product. A size chart is that kind of fact, once per product type, usually stored where agents cannot see it. The wider pattern is in what AI shoppers get wrong about specialist products; this guide is about the chart.

Why does an assistant answer the sizing question badly?

Since 21 August 2026 every Liquid storefront exposes ten storefront tools to browser-based agents, and every store also serves a catalog endpoint at /api/ucp/mcp and the older /products.json. Across those surfaces an agent can read a product’s title, description, options and option values, images, price and availability, and per-variant price and stock. It reads “S / M / L” as option values. It does not read what S means in centimetres, because that fact is in no field those surfaces return. On 5 September 2026 we crawled 41 public storefronts and read /products.json, the WebMCP tools, /api/mcp and /api/ucp/mcp on each: metafields were invisible from outside on 41 of 41. The surface-by-surface account is in which product data AI agents can actually read.

That leaves the product page, which a browsing agent can fetch. What it finds depends on how you built the chart:

• An image. The most common format, because a designer made it once. To an agent it is pixels: text recognition, then a guess whether the row that says “M” belongs to the column that says “55–58” or the one that says “21.7–22.8”. The storefront tools never return the image’s contents at all.
• A PDF. A link to a file on another URL. An agent reading get_product sees a link in the description at best; opening it is another fetch, another parse, the same column-guessing problem.
• A theme-rendered table. Better: the rows are text. But they sit inside a tab, an accordion or a pop-up, as HTML the agent has to find, and only an agent that reads pages rather than calling tools will see them.
• A metafield. If you have done the disciplined thing and stored the chart as a metafield or a metaobject, you have rows an agent could use perfectly, and no surface carries them.

None of this is a defect in the tools; they read the product record the way the storefront does, and a size chart has no fixed place in that record. The result is the same in every case: the assistant knows the product comes in S, M and L and cannot say which one a 56 cm head needs. It lists the options, tells the shopper to check the chart, or guesses. Guessing produces returns.

What does Shopify offer for size charts?

Shopify’s own guidance treats a size chart as a metafield: “If you sell clothing and you want to display a size chart for your products, then you might add a Product metafield called Size chart”, and “You can then display the size chart as a pop-up on your product pages” (help.shopify.com, Metafields, read 12 September 2026). The linked tutorial builds a page reference metafield and connects it to a pop-up block: “With metafields, you can add a page reference to a pop-up block that displays a link on your product pages”, and the chart is a page where “You can add images and other media using the rich text editor” (help.shopify.com, Adding a pop-up size chart to your product pages, read 12 September 2026). It needs a theme that supports dynamic sources.

That is a good design for people. For an agent it is two hops (a metafield the tools do not return, pointing at a page the tools do not return) ending in whatever you pasted into the rich text editor, which is very often the image again.

Metaobjects are the other half of the toolkit, for “when your data is best represented by multiple fields”, with a definition and entries, and “Your metaobject can be referenced by metafields or used stand-alone” (help.shopify.com, Metaobjects, read 12 September 2026). A size chart is exactly that shape.

On the syndication side, Agentic Storefronts sends products to ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta through Shopify Catalog, and Catalog Mapping steers what goes. Its scope is exact: “You can map different data sources to your product title, description, and category fields” (help.shopify.com, Mapping your product data sources for Shopify Catalog, read 12 September 2026). There is no size chart row. The only way a chart’s numbers reach the Catalog is as sentences in the description.

Most guides about size charts on Shopify, and most apps in the category, are about showing the chart to a person: a pop-up, a tab, a recommender on the page. They do that well, and they are not the problem here. The problem is that whatever they render, an agent cannot read it as data.

Chart formats, and whether an assistant can read them

How the chart is stored	Returned by the storefront tools or catalog endpoints?	Readable by an agent that fetches the page?	Usable as rows?
Image (PNG/JPG) in the description or gallery	No (the URL travels; the contents do not)	Only with text recognition; column matching is a guess	No
PDF link	No	Only with a second fetch and a parse	Rarely
HTML table rendered by the theme (tab, accordion, section)	No	Yes, as page text, if the agent finds it	Sometimes
Pop-up page via a page reference metafield	No (neither the metafield nor the page)	Only by following the link, and only as whatever the page holds	Depends on the page
Option values (S, M, L)	Yes, on every surface	Yes	Labels only; no measurements
Structured rows (metaobject or JSON metafield: size, min, max, unit)	No (metafields invisible on 41 of 41 stores, 5 September 2026)	No, unless the theme also renders them	Yes, through a tool that reads them

Dates: help.shopify.com pages read 12 September 2026; surface behaviour from our reads of 2, 5 and 12 September 2026, set out in the product data guide.

The last row is the interesting one. Structured rows are the only format an agent could use without guessing, and the only format that today reaches no surface at all. The fix is not to abandon the format. It is to keep it and add the tool.

The data model that works

A size chart an agent can use is a table with one row per size and, for each row, the measurement range that maps to it:

• One chart per product type, not per product. Helmets share a head-circumference chart; a jacket line shares a chest chart; shoes share a foot-length chart. Each chart is a metaobject entry (or a JSON metafield holding the same rows).
• One row per size: a label that matches your option value exactly (“M”, not “Medium” if the variant says “M”), a minimum, a maximum, and the unit in the column name (head_circumference_cm, chest_cm, foot_length_mm). Store numbers as numbers, not as “55–58 cm” text, though a tool can parse the text form if that is what you have.
• A link from every product that uses the chart: a metaobject reference metafield on the product (custom.size_chart, say) pointing at the chart entry.
• Keep the rendered chart for people. Point the theme’s table or pop-up at the same metaobject, so the visible chart and the rows cannot drift apart.

Here is our demo store’s version, and it is demo data, not a real product: the Cedar Road Helmet on our development store carries a chart with three rows, S 51–54 cm, M 55–58 cm, L 59–62 cm, keyed on head circumference. “My head measures 56 cm, which size?” resolves to one row, M, by arithmetic. Nothing to interpret. A tool that has the rows can answer with the row, then check whether the M variant is available in the saved catalog copy, and at what price.

Two things this model deliberately does not do. It does not predict fit between rows (a 58.5 cm head sits between M and L; the honest answer names both and says so), and it does not replace the brand’s fit advice (“runs small, size up”). Put that advice in the description, where every surface reads it; keep the rows in the chart.

How to check your own store

Start with the manual version, in fresh sessions, so no earlier chat teaches the assistant your chart:

1. Pick one sized product and note two rows: one for a measurement in the middle of a size, one on a boundary.
2. Ask a consumer assistant, in a new conversation each time, in a shopper’s words: “My head measures 56 cm. Which size of the [product] at [store] should I order?” Record the answer verbatim, with the assistant and the date. Repeat with the boundary measurement.
3. Compare to the chart. “Here are the sizes, check the chart”, a size with no reasoning, or a size that contradicts the row: each says the assistant did not read the rows.
4. Ask which size is in stock. An assistant that names the right size may still report the product’s stock rather than that variant’s; that is a separate mechanism with its own fix.

Consumer assistants add their own retrieval and caching, so this tells you what a shopper heard that day, not what every agent reads. A simulated check goes one layer down: it calls the models through their developer APIs against the storefront tools and shows the tool responses each answer was built from, so an unreadable chart shows up in the trace (the agent called get_product, received option values, and had nowhere to get centimetres from). Both routines are in how to check what AI says about your store.

What StoreKnows’ “Recommend a size” tool does

StoreKnows reads the store’s catalog into a saved copy: products, variants, prices, availability, options, metafields, and the metaobjects those metafields reference, which is where size charts live. When it finds a chart with numeric ranges and products that reference it, it proposes a fix called “Recommend a size”. The tool’s job is narrow: given a product and a measurement, find the row the measurement falls in and return it.

The answer is the row, not an opinion: the recommended size label, the matched row as stored (so the agent can quote “M, 55–58 cm”), whether the measurement fell inside a row, between rows or beyond the chart’s ends, any second row that overlaps at that measurement, and the matching variant’s captured availability and price when the label matches an option value. A product with no chart gets “no chart” and the sizes it comes in, not a guess.

The boundaries, stated once:

• Read-only. It answers questions. No cart, checkout or order access; nothing on your store changes.
• Saved catalog copy, not live stock. Availability is from the copy you approved, refreshed when you choose. The tool description says so to the agent; the app says so to you.
• Needs numeric ranges. A chart that is an image or free text has nothing to match; the app says so and lists the chart under what to add.
• Not a fit predictor. Between-row and off-chart measurements are labelled as such.
• You approve what becomes public. Nothing is served until you include a fix and publish; excluding it withdraws it.

Before any of that there is a preview. Open the proposed fix and type your own question (“My head measures 56 cm. Which size does the Cedar Road Helmet chart recommend?” is the one we use on the demo store). You see the answer and the rows it used, on saved data, before paying anything. If it picks a row you would not have picked, you have found a chart problem to fix, not a tool to publish.

Published fixes are served by a theme app embed beside Shopify’s own ten tools, so an agent that calls storefront tools finds “recommend a size” in the same list as get_product. Today that means Chromium-based browsers under an origin trial whose token expires on 17 November 2026 by our decode of 5 September 2026; we re-check it monthly. We have measured what metafield-backed tools do on a prepared store, though not on sizing questions specifically: on 5 September 2026, on a dev store of 144 bicycle products with specs in metafields, 14 questions went from 7 to 13 fully right for Google’s Gemini 3.8 Flash via the API and from 4 to 8 for OpenAI’s GPT-5.4 mini via the API, one run each, in a simulated check. Runs vary; treat it as a shape.

What to do this week

If your charts are images, the first move costs nothing but time: write the rows out as a metaobject, one entry per product type, reference it from each product, and point the theme’s pop-up or table at it so people keep seeing a chart. Put the brand’s fit advice in the description. Then ask the sizing question in a fresh session.

For the surfaces that read tools, which is where in-browser agents start, the rows need a tool. StoreKnows runs the simulated check on your own store for free, shows every answer beside the product data behind it, and lets you try “Recommend a size” with your own measurement before anything is published.

Results in this article come from simulated checks run by StoreKnows on 4 September 2026 against 34 public storefronts, a crawl of 41 public storefronts on 5 September 2026, and a run on 5 September 2026 against a development store. Questions were answered by OpenAI’s GPT-5.4 mini and Google’s Gemini 3.8 Flash, called through their developer APIs, not the consumer apps, and graded by a separate judge model. The Cedar Road Helmet and its chart are fictional demo-store data. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.