Too many variants: the limit is 2,048, and the number you remember is wrong

Daily variant creation limit reached, try again

If you are reading advice about splitting products at 100 variants, it is out of date. Shopify raised the ceiling twentyfold in October 2025. Two other limits did not move, and one of them is the one that will actually bite you.

Check your file in the converterRuns in this browser. Nothing is uploaded, and the check happens before you download.

Why Shopify raises it

Shopify’s adding-variants page states the current limits plainly: “You can create up to 2,048 variants for a product” and “Each product can have up to three options”. For years that first number was 100; it changed in October 2025, and an enormous amount of migration advice — including plenty still being published — has not caught up.

The second number did not change. 3 options is still 3, and that is the limit most catalogues hit first. Size × colour × material is fine. Adding a fourth axis is not, and Shopify’s own page sends you to a third-party app or to “customize your theme code to extract line item properties” for it.

The third limit is a rate limit rather than a ceiling, and it is the one that stops a bulk migration mid-flight. Shopify’s common import problems page lists Daily variant creation limit reached, try again: “For stores with 50,000 product variants (excluding Plus stores), no more than 1,000 new variants can be created by CSV uploads (or API) within a 24 hour timeframe. The 24 hour timer starts at the time of the first upload of the day.”

The 100-variant line that still matters

Here is why the old number has not entirely gone away. The same Shopify page carries a section titled “Considerations for adding more than 100 variants”, and what it lists is real:

  • “You can have up to 250 media items, such as images, per product. Each variant can have one media item applied, which must be from the product’s media list.” So you cannot give 2,048 variants their own photographs — plan imagery per colour, not per combination.
  • “Some third-party themes might not support more than 100 variants.”
  • “Some theme app extensions, public apps, and sales channels might not support more than 100 variants.”
  • “The Stocky app and the legacy Order Printer app don’t support more than 100 variants.”
  • Custom apps on the REST Admin API “must migrate to the GraphQL Admin API”.

So the import succeeds above 100 and the shop may not. That is a different kind of problem from a rejected file, and it deserves a different kind of warning.

How to find it in your CSV

Count rows per handle, excluding extra-image rows — those carry a handle and no SKU or option values, and counting them inflates every product. A pivot table on the handle column, or a count-if, gives you the per-product variant count in one pass.

Also count distinct option names per product. A file assembled from several source exports can easily end up declaring a fourth option on one product, and that fails regardless of how few variants it has.

How the converter prevents it

Three rules in src/lib/validate.ts, deliberately at different severities because the consequences differ.

too_many_variants is an error above 2,048 variants on one product. It is reported once, against the product’s own row rather than against every variant, because flagging 2,049 rows would bury every other finding in the report:

Product “hoodie” has 2,049 variants (maximum 2,048).

many_variants is a warning above 100. It is not an error on purpose: the file imports, and calling it a failure would be wrong. The message says what actually breaks — the 250-media cap, and themes, apps and sales channels that predate the increase — so you can check your theme before you rely on it. A warning never excludes a row from the export.

too_many_options is an error when a product declares more than 3 options, which is structural and cannot be worked around in the CSV.

All three count per product, not across the file: two products of 60 variants each are 120 rows and no warning, which is the correct reading of a limit that applies per product. The numbers themselves live as named constants in src/lib/shopify-schema.ts with the date they were verified, so the figure on this page and the figure the validator enforces cannot drift apart.

What a correct fix looks like

Above 2,048, split the product — there is no other option. Above 3 options, split it too, or move the fourth axis into a separate product; an options app can collect the customer’s choice but what it creates is a line-item property, not a variant, so no stock is allocated against it.

Between 100 and 2,048, do not split on the strength of the old advice. Migrate one high-variant product first, check that your theme renders every option and that your stock and packing-slip apps see all of it, and only then move the rest.

If you are importing tens of thousands of variants into a store that already has 50,000, plan around the 1,000-a-day rate limit rather than discovering it: split the catalogue into daily batches, and remember the 24-hour clock starts at your first upload, not at midnight.

Before you retry the import

  • Fix the file, not the symptom. Shopify reports the first failure it meets, so a second error usually appears once the first is cleared.
  • Import into a development store or a draft-status batch first, so a half-correct file cannot put wrong data in front of customers.
  • If you are overwriting existing products by handle, export your live products first: a blank cell in the import can erase a value that is currently there.

Column-by-column reference: the Shopify product CSV format. Nexum Gate is not affiliated with Shopify Inc.