Variant and Media Limit Auditor

Paste a Shopify store URL and this tool reads the public product feed, then measures every product against the four ceilings that actually bite: the 250 variant wall in Liquid, the 100 variant line where older apps start misbehaving, the 250 media files per product cap, and the hard limit of three option slots. It does not lecture you about the limits in the abstract. It hands you the product names.

Read the first row of any result before the other three. It counts products at or past 250 variants, and that is the finding that should worry you, because Shopify caps product.variants in Liquid at 250. A theme that loops over that list to build its variant picker renders the first 250 and stops, so on a product with 400 variants the last 150 cannot be selected and cannot be bought. They exist in your admin. They do not exist for the shopper.

October 2025 is why this tool exists at all. Shopify raised the variant ceiling from 100 to 2,048 for every merchant on every plan, which is genuinely a big change. What moved with it: nothing. Options stayed at three. Liquid still stops at 250. The 250 media files per product cap did not move either, and a Shopify staff member confirmed as much in the developer forums when merchants asked. So the platform now lets you build a product that your own storefront cannot fully render and your own media budget cannot fully photograph.

One honest thing before you run it. The public feed shows variants as published, so every count here is a floor rather than an audited maximum. Anything unpublished, hidden from the Online Store channel, or sitting in drafts is invisible to a scan that has no login. If the admin says 340 variants and this says 250, the admin is right and the scan is reading a truncated payload.

That truncation is worth spelling out, because it changes how you read the table. Shopify documents the storefront product JSON as carrying a maximum of 250 variants in its variants array. A product that comes back at exactly 250 has therefore hit the payload ceiling, and it may hold anything from 250 up to the platform maximum of 2,048. The tool never reports 250 as the truth. It reports it as at least 250, which is the only claim the data supports.

Crossing one of these ceilings announces itself to nobody. There is no error, no email, no banner in admin. Shopify accepts the 251st variant and stores it, a theme that loops over product.variants renders the first 250, and the product page serves a subset of what the catalog says is for sale. The gap only becomes visible if something goes and counts, which is the entire job of this page. Every number it reports comes out of your own public feed, so you can reproduce any of it by pasting a store URL in and reading the rows.

DetailWhat this tool does
Data sourcePublic products.json on the storefront. No login, no API key, nothing written back
Products per request250, which is what one page of this scan reads
Scan depthUp to 8 pages, so up to 2,000 products per run
Check 1Products at or past 250 variants, where Liquid cannot reach the rest
Check 2Products over 100 variants, the line Shopify itself warns older apps about
Check 3Products approaching the 250 media files per product cap
Check 4Products already using all three option slots
Counting basisA floor, not a maximum. Published variants only, and the feed itself tops out at 250 per product
Media it can seeImages only. The feed carries no videos or 3D models, and those count against the same 250
OutputA table sorted by risk, every row named and linked to its storefront page
Changes made to your storeZero. The scan only reads. The request normally comes from our server, and if that endpoint is unavailable or rate limited it falls back to a public CORS proxy, which hands the store URL you typed to a third party service

What changed in October 2025, and what stubbornly did not

On 15 October 2025 Shopify raised the product variant limit to 2,048 for all merchants. The Admin API docs now put it plainly: by default, stores have a limit of 2048 product variants for each product. Before that the number had been 100 for years, and 100 is small enough that any apparel range with a decent colour run blew through it.

So far, so good. The problem is that a variant count is only one of four ceilings a product sits under, and the other three stayed exactly where they were.

CeilingBefore Oct 2025NowWhere it bites
Variants per product1002,048Admin and API. This one genuinely moved
Option slots per product33Admin. Try to add a fourth and the API returns an options over limit error
Variants Liquid can read unpaginated250250Your storefront theme. Shopify restricted this on purpose
Media files per product250250Photography and admin. Images, videos and 3D models share the one budget

Read that table twice and the shape of the problem falls out. You can now build a product with 2,048 variants. Your theme can show 250 of them. You can attach 250 media files to it, total, across every variant. And you still only get three ways to slice it.

None of this is a bug and none of it is hidden. It is just spread across four different pages of documentation, none of which are open while somebody in your team is adding the fifteenth colourway.

Why 250 is the number that should worry you, not 2,048

Shopify's Liquid docs are unambiguous about this. The product.variants object returns a maximum of 250 variants when unpaginated. Shopify's theme guidance says it restricted product.variants that way to prevent poor render performance in themes, and it states the consequence directly: any Liquid code that requires a complete set of product variants will not work as expected if the product contains more than 250 variants. The worked example in that guidance is a variant picker. Shopify's words for it are that the code intends to iterate through all variants for the product, and that it actually only iterates through the first 250 variants.

The last step is ours rather than theirs, because the docs stop short of spelling it out: if the picker only ever renders the first 250, then on a theme that has not been updated variant 251 onward never reaches the page at all.

Think about what most theme code actually looks like. A variant picker is usually a loop over product.variants that writes an option into a select, or a JSON blob the picker script reads. Both patterns hit the wall at the same place. Variant 251 onward never enters the page, so no click can reach it, so no shopper can buy it.

Shopify does provide a way out for theme developers. Newer themes are supposed to render option inputs from product.options_with_values, use the product_option_value object for availability and selection state, and load the specific variant on demand through the Section Rendering API with option value parameters, or through the Storefront and Ajax APIs. That works. It also requires somebody to have actually done it in the theme you are running, which for most stores means the theme developer shipped an update and you applied it.

So the honest version is this: past 250, whether your shoppers can buy those variants depends entirely on your theme. Not on your plan, not on your app stack, not on how the product looks in admin. That is a miserable thing to be uncertain about, which is why the tool flags every product at or past the line rather than trying to guess your theme's behaviour from a catalog feed.

There is no way to settle the theme side from a feed, so settle it by hand: open one of the flagged products on your live storefront and count what the variant picker actually offers. If the last option value you can reach lines up with the 250th variant, your theme is truncating. Shopify's admin flags the same risk with a warning that your theme may not be compatible with products over 250 variants.

The 100 variant line, and why old apps still care about it

The 2,048 announcement came with a warning attached, and it is worth quoting because it is the reason this tool keeps a separate 100 variant count. Shopify's changelog says merchants using apps that are not using the in-support GraphQL product APIs may have a downgraded or broken experience when creating or viewing products with more than 100 variants.

That is a statement about apps, not about your storefront. A product with 140 variants renders fine for shoppers. What can go sideways is anything in your admin stack that still reads products through the old REST product endpoints: inventory sync, feed exporters, bulk editors, ERP connectors, print on demand integrations. Some of those will show you the first 100 and act as if the rest do not exist, and a sync that silently sees 100 of 140 variants is a genuinely expensive way to find out.

Which is why the tool reports this line separately rather than folding it into one scary number. Over 100 is a prompt to audit your app stack. At or past 250 is a prompt to look at your storefront. Those are different jobs, usually different people, and lumping them together helps nobody.

Separately reported, though, does not mean mutually exclusive, and an earlier version of this tool got that wrong. Every product at or past 250 variants is also over 100, so it belongs in both rows, and it is usually the most exposed product in the catalog to an app still on the old REST endpoints. The over 100 row therefore counts every product over that line, including the ones already at the Liquid wall. If you hand that list to an inventory or feed vendor, the biggest products are on it.

The media cap did not move, and it is the tightest one

You can add a maximum of 250 images, 3D models, or videos to a product. That is one shared budget, not 250 of each, and it is the same number it was before the variant limit changed. When merchants asked in the developer forums whether the media cap would rise alongside variants, the answer from Shopify was that a 250 product media limit increase was not included as part of the 2048 variant limit increase.

Put the two numbers next to each other and the arithmetic gets uncomfortable fast. A product allowed 2,048 variants and 250 media files gets, at best, one photo per eight variants. Even a modest range feels it: 30 colours at 6 photos each is 180 files, which fits, but add a size chart, a fabric detail shot, a video and a couple of lifestyle images and you are into the 200s with no colourways left to add.

Two more details that make the real number worse than the one this tool can show you. First, the public feed exposes an images array and nothing else, so any video or 3D model on the product is invisible to the scan while still consuming the same budget. Second, product images have their own constraints regardless of count: up to 5000 by 5000 pixels or 25 megapixels, and under 20 MB per file to upload at all.

So treat the media column the way you treat the variant column. It is a floor. If the scan says 214 images, the product has at least 214 media files, and the true figure is 214 plus whatever video and 3D content sits alongside them.

Planning a shoot rather than auditing one? The Variant Image Calculator works out how many photos a given option structure needs before you book anything, and our guide to adding 50 or more images to one product covers what the admin does when a gallery gets long.

Three option slots, and the day you need a fourth

This is the quietest of the four checks and the one merchants hit with the least warning. Shopify allows a maximum of three options per product. The API is blunt about it: try to create a fourth and you get an options over limit error saying you can only specify a maximum of 3 options.

Colour, size and fit. Or colour, size and material. Or width, length and finish. Whichever three you picked when the product was created, that is the shape of that product forever, unless you rebuild it. The variant limit rising to 2,048 does not give you a fourth axis, it just lets you fill the existing three more densely.

The reason this shows up in a limit audit at all is that it changes what your options are when you hit one of the other ceilings. A product using two option slots has room to restructure. A product already at three has none, and the only route past it is splitting the product, which is a catalog decision rather than a settings change.

Want to see where a given option structure lands before you build it? The Variant Combination Calculator multiplies out the combinations and shows you which ceiling you hit first. It takes two minutes, and it is the cheapest moment there will ever be to change the structure.

How this tool counts, and every reason the count is low

The scan requests /products.json from the storefront, 250 products at a time, and walks forward a page at a time until the catalog runs out or the scan hits its 8 page ceiling. For each product it counts the variants array, counts the images array, counts how many option slots the product declares, and reads the option values off the variants themselves. Then it applies the four checks and sorts by risk.

Everything about that pipeline biases the numbers downward, and you should know each reason:

  • Published products only. The public feed serves what the Online Store sales channel serves. Drafts, archived products and anything published to other channels only are simply absent.
  • Published variants only. A variant that is not available on the Online Store does not appear, so a product can carry more variants in admin than the feed shows.
  • The feed truncates at 250 variants. Shopify documents the storefront product JSON as containing a maximum of 250 variants in the variants array. Any product reported at exactly 250 is at that ceiling, and the tool labels it as at least 250 rather than pretending the number is exact.
  • Images only, no video, no 3D. The feed carries an images array. Videos and 3D models count against the same 250 media budget and never show up here.
  • One market. The feed answers as your primary storefront serves it, so catalog differences per region are invisible.
  • Up to 2,000 products. Past that the scan stops and says so at the top of the results, loudly. It never reports a partial scan as if it were a whole catalog.

Next to the variant count sits a second number: combinations. Take the distinct values actually sitting on that product's variants, one set per option slot, and multiply them. A product carrying 18 colours across 10 sizes has a grid of 180, and if only 170 variants exist then 10 combinations are unfilled. That is the number that tells you how much room is left before the next colourway crosses a line.

One deliberate choice inside that calculation, because it changes the answer a lot. The feed also publishes a declared list of values per option, and the tool ignores it. Running the scan against a live catalog turned up products declaring 12 colours, 17 sizes and 2 widths while carrying 17 variants, all of them one colour in one width. Multiplying the declared lists gave 408 combinations for a 17 variant shoe and shoved a dozen perfectly healthy products to the top of the risk table. Reading the variants instead gives 1 by 17 by 1, which is what the product actually is.

What to actually do about each finding

Four checks, four different answers. Getting these the wrong way round wastes real money, so here they are separately.

Past 250 variants. The fix is structural: stop asking one product to be the whole range. Split the monster into several products, one per colour or per family, and each resulting product gets its own budget back. Its own variant count, its own three option slots, its own 250 media files. Then the shopper problem becomes a presentation problem, because they need to move between those listings without noticing the seam. That is what Rubik Combined Listings groups separate colour products into one listing with swatches does, on the product page and on the collection page, and it works without Shopify Plus. Worth knowing for comparison: Shopify's own Combined Listings app requires a Plus or enterprise plan. You can see the grouped behaviour running on a live storefront in the combined listings demo store, and plan the split first with the Product Grouping Planner.

Near the 250 media cap. Say the unglamorous part first: no app raises this cap. It is Shopify's number, it applies to every plan, and anybody selling you a way around it is selling you something else. What you can change is whether the media you can afford to keep resolves to the right variant. Shopify gives each variant one featured image, so a shopper picking Rust still scrolls past every other colour in a shared gallery, which pushes merchants to upload more files to compensate. Rubik Variant Images assigns a whole image set to each variant instead, so the gallery filters down to that variant's own media and a smaller library does more work. It supports images, videos and 3D models, loads through Shopify metafields with no external API calls, and it is free to install at 5.0 stars across 419 ratings as of August 2026. See it filtering on a real storefront in the variant images demo store. If a product is genuinely at 250 media and still needs more, you are back to splitting it.

Over 100 variants. Nothing to do on the storefront. Go through your installed apps and ask each vendor whether they are on the current GraphQL product APIs. Anything doing inventory, feeds, bulk edits or fulfilment is worth checking first, because those are the ones where seeing 100 of 140 variants turns into a wrong number somewhere expensive.

All three option slots used. Nothing is broken today. Note the products, because when one of them needs a fourth axis the answer is a catalog split rather than a settings change, and it is much cheaper to plan that before the range grows than after. The Separate Products vs Variants comparison walks through which structure fits which catalog.

One correction we make a lot, because the two apps get swapped constantly: variant image filtering inside a single product is Rubik Variant Images, and linking separate products together with swatches is Rubik Combined Listings. A product that blew past 250 variants is a Combined Listings case, because the fix is splitting it. A product drowning in media inside one listing is a Variant Images case. Pointing those the wrong way round wastes a month.

Planning so you never see this page again

Ceilings are much cheaper to design around than to discover. A few habits that help:

  • Do the multiplication before you create the product. Colours times sizes times the third thing. If the answer is over 250, the product is going to be split eventually, so split it at the start while it has no reviews, no sales history and no inbound links.
  • Budget media per variant, not per product. Divide 250 by the number of variants you expect and see what you get. Twelve colours across five sizes is 60 variants, which allows four files each with 10 left for the shared shots. Forty colours does not.
  • Do not spend the third option slot casually. An option with two values that could have been a tag or a separate product has just consumed a third of your structural flexibility permanently.
  • Rerun this after every bulk import. Catalogs cross ceilings during imports, not during careful admin work, and nothing warns you.
  • Check the theme, not just the numbers. The 250 variant wall is a theme behaviour. Two stores with identical catalogs can be in completely different shape depending on how their theme builds its picker.

Our longer write up on managing images once you have 2,048 variants available goes through the media side of this in more depth than a tool page can.

Related Tools

What are Shopify's variant and media limits in 2026?

Four numbers matter. A product can have up to 2,048 variants, raised from 100 on 15 October 2025 for all merchants. A product can have a maximum of three options, unchanged. Liquid returns a maximum of 250 variants when unpaginated, so themes see 250. And you can add a maximum of 250 images, 3D models, or videos to a product, which is one shared budget across all three media types.

Why does the tool treat 250 variants as more serious than 2,048?

Because 2,048 is what the platform allows and 250 is what your storefront can render. Shopify restricted product.variants in Liquid to 250 deliberately, to prevent poor render performance in themes, and its theme guidance says any Liquid code that requires a complete set of product variants will not work as expected if the product contains more than 250 variants. The worked example there is a variant picker, and Shopify's own note on it is that the code intends to iterate through all variants and actually only iterates through the first 250. The conclusion is ours rather than a line in the docs: on a theme that has not been updated, variant 251 onward never reaches the page, and a variant that never reaches the page is not one your shoppers can select or buy.

Does every theme break past 250 variants?

No, and that is exactly why this is uncomfortable rather than simple. Shopify added APIs for theme developers to handle high variant products: rendering option inputs from product.options_with_values, reading availability from the product_option_value object, and loading the specific variant on demand through the Section Rendering API with option value parameters, or through the Storefront or Ajax APIs. A theme built or updated to use those is fine. A theme that loops over product.variants to build its picker is not. The scan reads your catalog, not your theme, so it flags the product and leaves the theme question to you.

Why does the tool say at least 250 variants instead of giving me the real number?

Because the public feed cannot give it. Shopify documents the storefront product JSON as containing a maximum of 250 variants in the variants array, so a product with 900 variants and a product with 251 both come back looking identical. Reporting 250 as a fact would be wrong. At least 250 is the strongest claim the data actually supports, and your admin has the exact figure.

Why is the count a floor rather than a maximum?

Three reasons stack up. The public endpoint serves only what is published to the Online Store sales channel, so drafts, archived products and other channel exclusives are missing entirely. Variants unavailable on the Online Store are missing too. And the payload itself truncates at 250 variants per product. Every one of those pushes the number down, never up, so what you get is a lower bound on your exposure.

Does the media count include videos and 3D models?

The 250 cap does. This tool cannot see them. The public products.json feed carries an images array and no media array, so videos and 3D models are invisible to the scan while still consuming the same shared budget. If a flagged product has video on it, the true media count is higher than the number shown, which matters most for the products already sitting in the 200s.

Can an app raise the 250 media limit?

No. It is Shopify's cap and it applies on every plan. When merchants asked in the developer forums whether it would rise alongside the new variant limit, the answer was that a 250 product media limit increase was not included as part of the 2048 variant limit increase. What an app can change is whether the media you have resolves to the right variant, so a smaller library covers more ground. Anyone claiming to raise the cap itself is describing something other than what they built.

Why does the tool flag products over 100 variants when the limit is now 2,048?

Because Shopify's own changelog attached a warning to the increase: merchants using apps that are not using the in-support GraphQL product APIs may have a downgraded or broken experience when creating or viewing products with more than 100 variants. That is about your app stack rather than your storefront. Inventory sync, feed exporters, bulk editors and fulfilment integrations are the ones worth checking, because an app that quietly reads the first 100 of 140 variants produces a wrong number somewhere costly.

Can I add a fourth option to a product?

No. Three is the maximum and the increase to 2,048 variants did not change it. The API returns an options over limit error stating you can only specify a maximum of 3 options. If your product needs a fourth axis, the route is splitting it into several products and grouping them for the shopper, not a setting you have missed.

My product hit a ceiling. Should I split it or restructure it?

If it is past 250 variants, split it. Nothing else gives the budget back, and a split product gets a fresh set of everything: its own variant count, its own three option slots, its own 250 media files. If it is only using two option slots and sits under 250 variants, you still have room to restructure inside one product. The question to ask is whether the range is going to keep growing, because a split done early is cheap and a split done after a product has reviews, sales history and inbound links is not.

Which Rubik app fits which finding?

A product past 250 variants is a Rubik Combined Listings case, because the fix is splitting the product into several listings and linking them so shoppers see one thing with swatches on the product page and the collection page. A product drowning in media inside a single listing is a Rubik Variant Images case, because it assigns a separate image set to each variant so the gallery filters instead of showing every colour to everyone. The two get swapped constantly and pointing them the wrong way round wastes a month.

Do I need Shopify Plus to split a product into grouped listings?

Not with a third party app. Shopify's own Combined Listings app requires a Plus or enterprise plan, which is the usual reason merchants think grouping is out of reach. Rubik Combined Listings does the grouping on any plan, and it is free to install at 5.0 stars across 66 ratings.

How many products can this tool scan?

Up to 2,000, which is 8 pages of 250. The 250 figure is products per request, which is what one page of this scan reads, and it is not a limit on your store or on the endpoint. If your catalog is bigger, the results say so at the top and tell you exactly how many products were covered, so you never see a partial scan presented as a full audit.

Why did the scan fail on my store?

The error message names which case you hit, because they need different answers. A web page coming back instead of a product feed usually means the domain is not a Shopify storefront or a custom frontend is serving it. A Shopify page instead of the feed points at a password protected storefront, a headless setup, or the endpoint being blocked at the CDN. A feed too large to read is a fetch size ceiling on our side and means nothing is wrong with your store. Zero products means the endpoint answered correctly with an empty published catalog. In most of these cases the myshopify.com domain works when a custom domain does not.

Does this need access to my Shopify admin?

No. It reads the products.json endpoint that every Shopify storefront publishes, the same data any visitor's browser can request. No login, no API key, no app install, nothing written back. That also means you can point it at any public store, including a competitor, since nothing private is involved. One caveat on where the request comes from: normally our own server fetches the feed, but if that endpoint is unavailable or rate limited the request may be routed through a public CORS proxy instead, which means the store URL you typed is handed to a third party service, so do not paste a URL you would not want seen.

How often should I run this?

After every bulk import, and before every season drop. Catalogs cross ceilings during imports rather than during careful admin work, and nothing warns you when it happens. Running it monthly on an active catalog is enough to catch a product the week it crosses 250 rather than the quarter after.