Shopify Product Options: The Complete Guide

Most stores reach a point where the product page has to ask the customer a question. What name goes on the necklace. Which font. What the gift note should say. When they want it delivered.

Shopify does some of this natively and some of it not at all, and the line between the two is not obvious from the admin. This guide draws that line: what an option actually is on Shopify, when variants are the right answer, when they are the wrong one, how custom option data reaches your order, and what it takes to charge for one.

If you read the first three sections and conclude that variants are enough for your store, that is a good outcome. Use them. Nothing you bolt on matches them for inventory and reporting.

What "product options" actually means on Shopify

The word gets used two ways, which is most of the confusion.

Shopify's meaning. In the admin, an option is a named axis of a product — Size, Colour, Material — and each combination of option values is a variant. Options exist to generate variants. Shopify's documentation puts it plainly: "Each combination of option values for a product can be a variant of that product."

What merchants usually mean. Anything the customer picks or types before adding to cart. Engraving text, a monogram, a delivery date, a photo upload, a gift-wrap checkbox.

That second kind mostly is not a variant. It is a line item property — a name and value pair that rides along with the item in the cart and lands on the order. Shopify supports these at the theme level: line item properties let customers "add custom information to a line item," captured through form inputs named properties[property-name] inside the product form.

The distinction worth holding onto: a variant is a thing you sell; a custom option is information attached to a thing you sell. A variant has an identity, a price and a stock level. A property is a label and some text.

One more thing people sometimes mean, worth ruling out: metafields. Those are custom fields you fill in — care instructions, a spec sheet, a fabric name. If the shopper is the one typing, metafields are the wrong tool.

When Shopify variants are the right tool

Variants are the better answer more often than options apps like to admit. Reach for them when any of these is true.

You need to know how many are left. Inventory is tracked per variant. If "Large / Navy" can sell out independently of "Small / Navy", it has to be a variant. Nothing built on line item properties holds stock, and no app changes that.

Each combination has its own price or photo. Both live on the variant. Per Shopify's docs, each variant carries its own price, inventory, shipping settings, image, SKU, barcode, HS code and country of origin. A 500g bag costing more than a 250g bag is textbook variant work.

You need it in reporting, collections or feeds. Variants are first-class everywhere in Shopify — analytics, automated collections, discounts, product feeds, POS. Line item properties are not.

The list is closed and short. Three sizes and four colours is twelve variants: a comfortable product. And the ceiling moved — on 15 October 2025 Shopify raised the limit from its "historical variant limit of 100" to 2,048 variants per product for all merchants (Shopify's changelog). If you last checked when 100 was the number, a product you assumed was impossible may be fine now.

A rule of thumb: if you would ever ask "how many of that exact combination do I have left?", it is a variant.

When variants are the wrong tool

The answer is open-ended. "What name should we engrave?" has no list, and you cannot pre-create a variant per name. Shopify itself points here: for products needing more than the native limits, "you can use a third-party app from the Shopify App Store, or customize your theme code to extract line item properties, so you can get custom requirements from your customers."

The combinations explode. A tote in 12 colours, 6 sizes and 4 materials is 288 variants — 288 rows to price, photograph, name and stock-count, from three axes. Add a strap length and you have run out of slots entirely: each product can have up to three options, so the fourth axis has nowhere to live even though 2,048 variants is nowhere near binding. The option limit bites long before the variant limit does.

Nothing is being stocked. Gift wrap, a rush fee, a handwritten card, a requested delivery date. Turning these into variants multiplies your variant count for something you will never count, photograph or run out of.

Every one is different anyway. Made-to-order, print-on-demand and custom fabrication produce a unique item per order — no combination to track, because no two are the same. What you need is the customer's brief on the order in a form your workshop can read.

If you are in one of those four, you need custom options.

The four kinds of option merchants actually need

Nearly every request falls into one of four shapes. Knowing which you have tells you what to build and whether money is involved.

Free text needs a character limit that matches the physical object. "Alexandra-Rose" will not fit on a 20mm bar, and the customer should find that out on the product page rather than in an email from you two days later.

Choice is the judgement call. If your three candle scents are stocked separately, make them variants; if they are poured to order from bulk, a choice field keeps your catalogue at one product instead of three. Choices render as a dropdown, radio buttons, or colour and image swatches — see choice fields and swatches for when each reads better.

File upload replaces emailing every buyer after the order, which costs you a day and some of them never reply. Uploading at purchase attaches the file to the order, so whoever fulfils it does not have to go looking. See collecting image uploads.

Paid extra is meaningfully harder than the other three, for reasons covered below.

Most product pages mix them: a photo print might take a size choice, an upload, free text for a caption and a paid extra for the frame. Everfield ships 14 input field types plus 6 display-only blocks such as headings and a size chart — the full list is in field types.

How custom option data reaches your order

This decides whether your fulfilment process works or quietly breaks. There are two places a custom answer can live on a Shopify order.

Line item properties attach to a specific item. Buy two mugs with different engraving and each line carries its own text — Shopify treats properties as part of the line's identity, and per the Cart API docs, "if the same items have differing prices, properties, or selling plans, then they'll be split into their own line items." Two mugs, two engravings, two lines, no ambiguity.

Cart attributes — also called order attributes or note attributes — attach to the whole order. Shopify describes them as "custom form fields that you can use to collect additional information from your customers on the cart page", and what you collect displays in a note on the order in the admin; the order page shows it in the section labelled Additional details. They are set through a POST to /cart/update.js with an attributes object.

Which to use follows from the question, not from taste. "What should this item say?" is a line item property, because the answer differs per item. "When do you want the order delivered?" and "How did you hear about us?" are cart attributes, because there is one answer per order.

Why it matters for fulfilment and exports:

• The property name is your field's label, copied exactly. Call it Engraving text and that is the string everything downstream matches on — your print-on-demand app's field mapping, your packing slip template, any export you build. Settle the wording before you publish.
• Reading them in bulk takes a step you have to add. On the order page itself they are always there, under the line item. Shopify's built-in order export is a fixed set of standard order and line item columns and its documented field list does not include line item properties, so getting them into a spreadsheet in bulk means an export app or the API.
• Packing slips can print them, but not out of the box. line_item.properties is one of the documented packing-slip variables, so a short loop added to your packing slip template puts each property under its item. Add it before your first real order, not after.
• Properties whose name starts with an underscore are hidden from the customer at checkout. Shopify: "You can add an underscore to the beginning of a property name to hide it from customers at checkout" (docs). Apps use this for internal bookkeeping — keys like _npi_addon_id on an order are that.

Everfield follows the same split: a product-page experience writes line item properties, a cart experience writes order attributes. One exception is worth knowing — if a line already in the cart carries a property whose name matches one of the cart experience's field labels, the cart experience edits that line's property instead of writing an order-level attribute. Where each lands in your admin is covered in find what customers entered on an order.

Charging for an option, and why it is harder than it looks

Adding a text box is easy. Adding £4 to the order because the customer ticked "gift wrap" is not, and the reason is structural.

On Shopify, price lives on the variant. A line item property is a name and a value. It has no price field and no supported way to acquire one, so there is no such thing as "a property that costs £4" — the money has to come from something Shopify recognises as sellable. That leaves three approaches, each with a real cost.

1. Make the paid option a variant. Native and reliable, until it does not scale. Gift wrap as a variant axis doubles every variant on the product and eats one of your three option slots. Fine for one product, unworkable across a catalogue.

2. Invoice afterwards. Take the order, then send a second invoice or draft order. It costs a support conversation per order, and some of those customers never pay.

3. Add a hidden add-on product to the cart. The surcharge is a real variant on a hidden product, added as its own cart line when the option is selected. This is what most options apps do, because it is the only approach that scales and collects the money at the original checkout. The trade-off is an extra cart line and an app-managed product in your catalogue.

Everfield uses the third. On publish it creates a hidden Add-ons product — unlisted, so it stays out of storefront search, your sitemap and recommendations — with one variant per distinct combination of option label and price. Those variants are untracked and non-shippable, so a surcharge never blocks checkout on stock or shipping rules, and because it is a genuine Shopify line, a discount applies to it like any other line.

Five things worth knowing before you plan around it:

• Paid options work on product-page experiences only. A cart experience has no price boxes at all — the cart runtime cannot attach add-on lines.
• "Price per character" is display-only. It shows a running estimate as the customer types and charges nothing. To collect money, use Add-on price.
• A price only charges once the add-on variant behind it exists. Everfield provisions those variants when you publish. If provisioning fails — most often a permission the app has not been granted yet — the surcharge still shows to customers and nothing is charged. The dashboard says so in a banner and has a Retry that fixes it; check it after your first publish with prices.
• Merging the surcharge into the product's cart line is a display choice, not a money one. Both modes charge identically and the order always itemises each paid option separately. Merged is the default, but it needs Shopify's cart-transform support in your store; where that is unavailable — and always for subscription items — the surcharge stays on its own line and is still charged.
• The hidden products show up in your Shopify Products list. The Add-ons product, and while the merged cart display is on, a second bundle-parent product the merge needs. They look like clutter. Deleting one stops the surcharges charging until you press Retry.

The full walkthrough, including per-choice pricing and quantity-based charging, is in charge for an option.

Where options belong: the product page or the cart

The product page suits an option whose answer is about this item — engraving, font, uploaded artwork, a per-item gift message. The customer is looking at the thing while they answer, and the value attaches to that line, so two items can carry two different answers.

The cart suits an option whose answer is about the whole order — a delivery date, a PO number, "leave it with a neighbour". Asking these per item means asking repeatedly and getting contradictory answers.

Two practical notes. Product-page options can be priced; cart options cannot. And cart placement depends on locating your theme's checkout button, which varies — cart placement covers automatic detection and the custom selector you fall back to when a theme is not recognised. If a question applies to the whole order but you only ever sell one item at a time, the product page is the better home anyway.

What to watch out for

These failure modes are consistent across every store that adds options, and most are avoidable if you know about them on day one.

Renaming a field changes the key on all future orders. The property name is the label. Rename Engraving to Engraving text and every order from that moment uses the new name while old orders keep the old one. Anything matching on the name — an export template, a fulfilment app mapping, a packing slip loop — needs re-pointing. Settle your labels before you publish.

Two fields sharing a label collide. Same key. If a product-page field and a cart field both say "Gift message", the same name is written in two places on the order. Keep labels distinct.

Hidden fields send nothing. A field hidden by a conditional rule is never validated, never saved and never charged, because the customer never saw it. Optional fields left blank are skipped rather than saved as empty. Both are correct, and both mean an empty column in your export is not necessarily a bug. See conditional logic.

Some themes defeat automatic placement. Options apps place the fields above your Add to cart button by finding the product form in the page. Themes that build that form unusually, or render it in JavaScript, defeat the search — and the symptom is that nothing appears at all. The fix is to place a block by hand in the theme editor, which is why Everfield ships an app block as well as an app embed. See troubleshooting options not showing.

Options are not inventory. The most expensive mistake here. A "Personalised" checkbox decrements nothing. If you have ten engravable blanks in the workshop, an options app will happily sell eleven. Anything you can run out of has to be a variant, or backed by one.

Only one published experience renders per placement. In Everfield, if two published product-page experiences target the same product, the first match renders and the second does not. Check that before assuming something is broken, and narrow them with targeting.

Quick-add buttons skip the options. Collection-page and quick-view add-to-cart bypasses the product page, so the fields are never shown. The item still adds — without the answers. Consider turning those off on products carrying required options.

How to add product options with Everfield

A first experience takes about ten minutes.

1. Turn on the app embed. In your Shopify admin go to Online Store → Themes → Customize → Theme settings → App embeds, switch on Everfield Product Options, and save. No theme files are changed. The dashboard deep-links you there with the toggle already flipped, but you still press Save yourself. See enable the app.

2. Create an experience. An experience is one set of fields with its own styling and targeting. Start from a template — Gift Message, Engraving, Photo Personalisation or Delivery Instructions — or blank. Engraving is built on a conditional rule, so on the Free plan you will be asked to upgrade before that one saves. See create your first experience.

3. Add your fields. Up to 20 per experience, drag to reorder. Every input field takes a label, optional help text and a Required toggle; type-specific settings appear as you need them — character limits on text, lead time and date bounds on dates, size and count on uploads. See required fields and validation.

4. Style it, then publish. Layout, container, labels, inputs and custom CSS, with five ready-made looks to start from — aim for fields that look like the rest of your product page rather than like an app. The live preview runs the same compiler as the storefront, so the markup and CSS you see are the real ones; a few runtime behaviours (the character counter, selection limits, variant-based rules) only run on the live page. See styling your options.

5. Place a test order. Fill the fields, check out, open the order. Product-page answers sit under the line item, cart answers under Additional details. People skip this step and regret it, because it is where you discover a label reads badly on a packing slip.

Some honest notes on limits. Conditional logic needs the Basic plan or above, and targeting needs Advanced; anything already built keeps working if you later move down a plan, because the gate only blocks adding new paid usage. Plans include a monthly allowance of widget views, and going over shows a banner rather than switching anything off. Uploads cap at 5 MB per file — that ceiling is Everfield's own, chosen to keep uploads quick; Shopify Files itself accepts images and generic files up to 20 MB. See plans and billing.

Where to go next

Anything you stock, price separately or report on is a variant — build it in Shopify and do not pay for an app. Anything the customer writes, uploads, picks purely to instruct you, or pays a surcharge for is a custom option, and Shopify has no built-in way to collect it on the product page.

For the full set of how-to guides, start at the help centre. Common questions are in the FAQ, and recent changes in the changelog.