Shopify Metafields vs Line Item Properties: Where Should Your Custom Data Live?
Almost every store I talk to eventually needs to attach extra information to something. A customer wants a name engraved on a pen. A wholesale buyer needs a purchase order number on the order. A product needs a care guide that appears on its page. A warehouse needs to know that a certain customer gets a handwritten card.
Shopify gives you several places to put that information, and they are not interchangeable. Choosing the wrong one is the most common reason a clean looking store turns into an integration headache later. I see it most often when a store owner or a theme developer picks whatever was fastest on the day, and then a shipping system, an ERP or an email platform cannot find the data.
This article walks through the options, what each one is good at, and how to decide.
Line item properties
A line item property is a piece of information attached to one product in one cart. The classic example is a text box on a product page that says “Engraving text”, whose value travels with that product through the cart, the checkout and into the order.
Because the data lives on the line, it stays with the right product. If a customer orders two pens with two different engravings, you end up with two lines, each with its own value. This is exactly what you want for personalization.
A few things worth knowing:
- The customer fills it in, so you are trusting typed text. Nothing stops a visitor from entering a novel, an emoji or something rude unless you add checks.
- Properties are plain text. There is no built in type, no list of allowed values, and no validation by default.
- A property whose name starts with an underscore is hidden from the customer at checkout, which is handy for internal values such as a product configuration code.
- Many theme and app builders create these properties for you, so the data may already exist in your orders under whatever name the app chose.
Product and variant metafields
Metafields are structured fields you define yourself and attach to things in your store. A product metafield holds information that belongs to the product, such as material, country of origin, or a link to an assembly guide. A variant metafield does the same for a specific size or color.
Metafields have types, such as text, number, date, a reference to a file, or a list. You can make them visible in the admin, show them in your theme, and read them through the API.
Use these for facts about the product that do not change per customer. If you find yourself copying the same sentence into a hundred product descriptions, that sentence belongs in a metafield.
Order metafields
An order metafield is information about the order itself, usually added after it is placed, by your team or by an app. Examples are a flag that fraud review is done, the ID this order has in your ERP, or the name of the warehouse that picked it.
This is also a good home for identifiers that connect Shopify to other systems. Storing the downstream ID on the order makes it far easier to match records later and to avoid creating duplicates. If you are building any kind of sync, I recommend this habit from day one. I explain why in Shopify Webhooks Missing Orders.
Customer metafields and tags
Information about a person, such as a loyalty tier, a wholesale terms agreement or a preferred shipping method, can sit in a customer metafield. Tags are the lighter option. They are quick to add and easy to filter, but they are just words, so they cannot hold structure like a date or a number.
My rule: tags for simple labels you will filter by, metafields for anything that has a shape.
Cart attributes and order notes
Cart attributes are loose pieces of information attached to the whole cart, such as a delivery date or a gift wrapping choice. They end up on the order as note attributes. Order notes are a single free text box.
These are quick to use, and many stores rely on them, but they cause the most downstream pain. A note is one blob of text with no structure. Some systems only read part of it. In one of my ShipStation projects, for example, only the first 255 characters of the order note made it across. I wrote about that in Why Custom Packing Slips Are So Hard.
Putting it together
Here is the short version I give clients:
- The customer types it, and it belongs to one product: use a line item property.
- It is a fixed fact about a product or variant: use a product or variant metafield.
- Your team or a system adds it to an order after the fact: use an order metafield.
- It describes a customer: use a customer metafield, with a tag for simple labels.
- It applies to the whole order and the customer entered it, such as a delivery date: use a cart attribute.
- Everything else: avoid order notes unless a person is the only reader.
Think about the reader, not just the writer
The question most people skip is who needs to read the data later. The storefront, the warehouse, the accountant and the email tool all read your data differently, and each of them may only see some of the places above.
A few examples of how it goes wrong:
- The packing slip system only sees three custom fields, so your per item engraving never prints. I cover this in ShipStation Custom Fields 1, 2 and 3.
- Your email platform builds its profile from orders, but your loyalty tier lives in a customer tag it does not read.
- Your accountant exports orders as a spreadsheet, and the purchase order number is buried in the note.
Before choosing, list every system that needs the data and check how each one gets it. If a system cannot read the place you picked, either pick a different place or plan a small integration to carry it across.
Validation and cleanliness
Because line item properties are free text, treat them as untrusted input. Limit the length in the form, and also check it again on the server side or in your integration, since a browser check is easy to bypass. Decide what to do with characters your engraver cannot produce. Decide how a blank value is handled. A little effort here prevents the kind of mistakes that end in a remake and a refund.
For metafields, set up definitions rather than creating them ad hoc. A definition gives the field a name, a type and a place in the admin, which means your team can edit it safely. Without one, values can be written through the API but stay awkward to manage.
Plan for access
If another system needs to read your metafields through the API, the app or integration needs permission for them, and some of them need to be exposed explicitly before the storefront can use them. Check the current Shopify documentation for the details of access, since these settings have changed over time.
Finally, document your choices. A short page that says “engraving text is a line item property named Engraving, the ERP order ID is an order metafield in the namespace we chose” saves a future developer, possibly you, days of detective work.
If you are unsure where something should live, or you inherited a store where the data is scattered, email kevin@kevinhq.com with a description of what you collect and who needs to read it. I can usually sketch a clean layout in a single reply.