Key Insights in 60 Seconds
Skim the highlights, then jump to the section that matches the decision in front of you.
What You'll Learn
A supplier sends a fabric composition. A cabinet arrives with three measurements that belong on the page. A stone comes with a certificate number buyers actually search for. None of it fits the fields Shopify gives a product out of the box, and the App Store has a shelf of listings ready to sell you the missing field by the month.
Shopify calls the built-in answer custom data, and it ships in two shapes — metafields and metaobjects — with a real boundary beyond which an app is still the right purchase. This page draws that boundary: what each shape is for, where native runs out, and what work you take back if you cancel the subscription.
The Quick Verdict
Key takeaway
Find the line that matches what you are storing; the rest of the page is the reasoning underneath it.
Your data class, and what it actually needs
| Your situation | Pick | Why |
|---|---|---|
| One spec value per product that you type in yourself — fabric, dimensions, a certificate number | A metafield | A native definition in Settings, and a theme with dynamic sources binds it to the page without code. |
| The same block of details is reused by dozens of products — a size chart, a care guide, a brand | A metaobject the product references | You correct one entry and every referencing product follows; a per-product field would hold that many copies. |
| The shopper types, uploads or picks the value before adding to cart | An app | Metafields are merchant-entered; the two buyer-input listings we priced in August 2026 run paid plans from $8.90 to $39.99 a month. |
| An app is already installed and you want to drop it | Find which class it is, then check the namespace | One whole class of these apps adds no new capability — just a nicer editing screen over fields you already have; what the app wrote into its own reserved namespace is the open question in the removal section below. |
Metafield or metaobject: what each one is for
Key takeaway
These are not three products competing for one job. They are three answers to a single question — who owns this value, and who types it in — and everything else follows from the answer: where it renders, what it costs, what breaks first. Get it wrong in the other direction and you pay a monthly subscription to store a paragraph of text.
Metafield vs metaobject vs app, by what each is for
| What you are comparing | Metafield | Metaobject | App |
|---|---|---|---|
| Where the value lives | On the record itself — a product, variant, collection, customer, order and more | In its own entry, which records point at through a reference field | In the app's storage, surfaced back into your admin |
| Who types it in | You or staff with the matching resource permission | You or staff, once per entry | Whoever the app allows — including the shopper |
| Reuse across records | None: the value belongs to one record | Built in: one entry, many referencing records | Whatever the app implements |
| Can it have its own page? | No | Yes, when Web pages is switched on: /pages/{url-handle}/{entry-handle}, and you pick the URL handle | Usually a page the app renders |
| What it costs | Part of the admin — no Shopify page we read prices it separately | Same | $4.99–$25 a month for the editor class; the capability classes we priced run from a free plan to $39.99 |
| Where it breaks | Buyer input, cart pricing, field shapes the admin does not offer | Same limits, plus no documented CSV route for entries | Ownership: values written into the app's own reserved namespace |
Compiled from the Shopify Help Center custom data pages and Shopify.dev custom data documentation, read August 2026. App pricing is the cheapest paid tier observed on each App Store listing on 1 August 2026.
The one-line test: one record or many?
If the value belongs to one record and nothing else needs it, that is a metafield. If the same object is quoted by many records and has to be corrected in one place, that is a metaobject — and each product points at it with a reference field. Everything else in this page is detail hanging off that one sentence.
It also helps to drop the habit of thinking metafields are a product feature. Our own corpus has used “products, variants, collections, customers and orders” as shorthand for years; the developer documentation treats that as an illustration rather than a boundary, and the API enum behind it lists 25 live owner types, from pages and blogs to markets, locations and B2B companies.
Metafields extend these models by letting you add custom data to any Shopify resource.
The size chart, done both ways
Shopify's own documentation uses a size chart as a metafield example: a clothing store adds a product metafield called Size chart and displays it as a pop-up on the product page. For twenty products that is exactly right — you write the chart where it is used, and nothing else has to know about it.
At four hundred products across five category shapes, the same approach stores four hundred copies of five tables. The metaobject version stores five entries and lets every product reference the one that applies, so a correction lands once. Same principle, different scale — and the official example describes the simpler form, not this one.
What kinds of data can a metafield hold?
Key takeaway
The type is not packaging. It decides what staff are allowed to enter, how the value renders, and whether it can become a storefront filter later. Choosing single line text because it is easy is the most common way to make a field that looks fine on the page and cannot be sorted, filtered or converted afterwards.
The reference fields that point at a metaobject
Reference types are the connective tissue of custom data. Twelve of them exist, and two matter for the decision in front of you: metaobject_reference points at entries from one definition, while mixed_reference can point at metaobjects from different definitions. The full set, as published:
- Product, variant and collection references
- Page, article and file references
- Customer, company and order references
- Metaobject reference, mixed reference and product taxonomy value reference
One documented behaviour is worth knowing before you build lists on top of these: if you delete a product or variant, Shopify automatically removes it from every list metafield that references it. That is convenient when a SKU dies and quietly destructive when someone deletes a product to “clean up” a catalogue.
Lists: what the API allows and what the admin offers
In the developer documentation most of those types have a list form too — 53 of the 60 basic and reference types, with boolean, id, JSON, language, money, multi-line text and rich text the exceptions. The admin definition screen is narrower: Shopify documents metafield lists for 13 non-reference content types — text fields, numbers and dates among them — and for 8 reference types, including products, files and metaobjects.
That gap is small but it is real, and it is one of the few places where an editor app buys you something other than a friendlier screen. If the shape you need has no list form in the admin, an app that can write the value through the API is doing work you cannot do yourself in Settings.
How does custom data reach your storefront without a developer?
Key takeaway
The most common dead end is not the definition — it is the page. A merchant creates the field, fills it for every product, opens the storefront and sees nothing. Nothing is broken: a value only appears where something in the theme has been told to render it.
Dynamic sources in the theme editor
Shopify's term for the mechanism is a dynamic source: data created and stored outside the theme editor that can be connected inside sections and blocks. Metafields, metaobjects and resource attributes all qualify. In practice you open a section setting, click the dynamic-source icon, and pick the field.
There is a documented ceiling on the bulk version of that action: up to 20 metafields in a single template through the multi-select icon, added one at a time. The architecture that makes any of this possible is Online Store 2.0, covered in our guide to Online Store 2.0 and theme architecture.
Note Shopify's own hedge: it says most metafields can be connected through the theme editor on a supporting theme, not all of them. JSON is the obvious example of a type the editor will not lay out for you.
When you still need Liquid
Two situations send you back to code, in Shopify's wording: a vintage theme that does not support dynamic sources, or a metafield type your theme does not support. Then you edit the theme, referencing the value directly — product.metafields.custom.your_field — which is Liquid, the theme language doing what the editor could not.
This is also where older comparison tables mislead. “Displaying metafield data requires code” was true before dynamic sources and remains true on a vintage theme; on a current Online Store 2.0 or Horizon-family theme it is a theme-editor job. Check which generation your theme belongs to before you budget for a developer.
Can shoppers filter your catalogue by a metafield?
Key takeaway
Faceted filtering is one of the most common reasons a merchant reaches for a paid app, and the answer here changes the bill. Shopify's first-party Search & Discovery app is listed at Free and, on any compatible theme, creates filters directly from metafield values — with a maximum of 25 filters for your store as the headline ceiling.
Two different gates decide whether a shopper ever sees a filter, and merchants routinely optimise against the wrong one: first, whether the field is even eligible; second, whether the catalogue is small enough for filters to render at all.
Gate one: which metafields can become a filter
Shopify publishes the eligible value types as a closed list, and it is short. Types outside it — money, date, rich text — have no filter option in the app, which is why the type you choose on day one decides whether this section is available to you at all.
- Single line text
- Single line text (list)
- Decimal
- Integer
- True or false
- Metaobject reference
- Metaobject reference (list)
Two consequences follow. Pick the type with filtering in mind on the day you create the definition, because converting a populated field later is work. And note that metaobject references are on the list, which is what makes a reusable entry — a fabric, a certification, a brand — filterable in the free Search & Discovery app.
Gate two: when filters stop showing at all
Eligibility gets you a filter; catalogue size decides whether anyone sees it. These ceilings are published on the same page and are the ones large catalogues actually hit.
Search & Discovery storefront filter ceilings
| Ceiling | Number | Where it bites |
|---|---|---|
| Filters per store | 25 | The whole store shares one budget of filters, not one per collection |
| Values shown in one filter | 100 | A long tail of sizes or materials is stored but not all shown |
| Unique values in one filter group | 200 | Grouped filters stop accepting new distinct values past this point |
| Filter groups per store | 1,000 | Rarely reached outside very large catalogues |
| Filter values per source, inside the app | 1,000 | The app's own editing view caps what it will list for one source |
| Products in a collection | over 5,000 | Collections larger than this display no filters at all |
| Results in a search | over 100,000 | A search returning more than this displays no filters at all |
Search and Discovery filters, Shopify Help Center, read August 2026. All figures apply to the free first-party app on the storefront, not to admin filtering.
Filtering your own product list in the admin
Backoffice filtering is a separate mechanism with its own ceiling: a maximum of 50 definitions per product metafield definition can be used to filter the Products list. It has nothing to do with what shoppers see, and confusing the two is how a store ends up buying a search app to fix an admin problem.
When is native custom data enough?
Key takeaway
The threshold below is ours, not Shopify's — the platform documents behaviour, not shopping advice. Run your own data class down the three columns and stop at the first one where every line is true for you.
- The value (or list of values) belongs to one record and nothing else quotes it
- You or your staff type it in; the shopper only reads it
- It fits a published content type — text, number, date, measurement, colour, money, file or URL
- Your theme can bind it, or you accept one Liquid edit
- The editing volume survives the product CSV or the bulk editor
- One thing needs several fields to describe it, not a single value
- Many products quote that same thing and you want to correct it in one place
- Shoppers should be able to filter by it — metaobject references are among the eligible filter types
- You accept editing it entry by entry: no documented CSV route covers metaobject entries
- It may deserve its own storefront page — the Web pages feature does that
- Anyone outside your team has to supply the value before checkout
- The value has to change price, bundling or cart presentation — that one is a developer-installed Cart Transform function, not a listing you buy
- Another system owns the data, or edits arrive faster than CSV and the bulk editor allow
- You need a field shape the admin does not offer — a repeater, a table inside one field
- Not on this list: a friendlier editor for the same native fields — test that class first
Most stores that land in column three land there for exactly one reason, and it is almost always the first line: someone other than you needs to type the value in. That is the boundary the next section prices.
Where custom data stops and an app starts
Key takeaway
The honest version of “do I need an app?” is not a yes or a no — it is five separate questions, and each one has a different answer and a different price. Four of them buy capability that metafields do not have. The fifth, and the easiest one to buy by mistake, buys a screen.
Class one is where most defensible app spend goes. A metafield cannot collect an engraving, a monogram or an uploaded file at checkout, because it is a merchant-entered field by design. The two listings we priced — PC — Custom Product Options and SC Product Options — differ on exactly that point: the first runs a free plan for live stores, while the second labels its free plan “Always free for development stores”, observed August 2026. Whether to buy one or build the picker is a deeper decision, and it belongs to our product configurator guide.
Class two is not something you install from a shelf. Shopify's documented route for custom data that changes money is the Cart Transform function API, whose input schema exposes product and variant metafields inside the cart line before pricing, bundling or presentation is altered. No page we checked names a specific app for this class, which is why this section quotes no price for it.
Class three starts where the CSV stops. Product metafields ride the product CSV; variant metafields do not, and metaobject entries have no documented CSV route at all. Once a PIM, an ERP or a supplier feed is the real source of truth, you are buying a pipe, not a field — one listing in that class, Metafields Manager, is $20 a month with a 14-day trial as of August 2026.
The app class most stores pay for by mistake
The fifth class adds no new capability to your store — the data model underneath is identical, and a better bulk-edit screen is worth something. It is an editing surface over the same native definitions: bulk edit screens, nicer field groups, preview panes. We priced eight of these listings on 1 August 2026, and their cheapest paid tiers run from $4.99 a month to $25 a month.
Cancelling one is not free, and it is fair to say what you take back. You define the fields yourself in Settings, in the admin's own screens. Bulk changes go through the product CSV at product level and the variant bulk editor at variant level. And when something behaves oddly at two in the morning, there is no vendor to escalate to — the field is yours now, along with the debugging.
The test is whether the app crosses into another class. If it is running scheduled imports, writing list types the admin does not offer, or copying definitions between stores, it has stopped being an editor and started being class three. If it is only making the same fields prettier to fill in, it is a convenience purchase — a legitimate one, but priced as such.
The limits Shopify publishes — and the ones it doesn't
Key takeaway
The headline number is up to 250 metafield definitions, and the caveat travels with it: the sentence does not say whether that ceiling is per store or per owner type, and no official page we have found resolves it. Plan against the tighter reading and you will never be surprised.
The other two published ceilings live where their decisions live: 20 metafields per template through the theme editor's multi-select, and 50 product metafield definitions available to the admin product-list filter. The storefront filter ceilings sit in their own table above. That is the complete set of numbers Shopify publishes for custom data.
Is custom data available on every plan?
The custom data manual pages and shopify.com/pricing, read in August 2026, mention no plan gate for metafields or metaobjects, and neither puts the word Starter next to custom data in either direction. That is an absence of documentation, not a documented entitlement.
Which matters most on Starter, the one tier where the gap could bite: shopify.com/starter now redirects to Shopify's general free-trial page, and shopify.com/pricing does not use the words metafield, custom data or Starter anywhere. If you are on Starter, open Settings and look before you plan around it — and treat any blog that promises “all plans” as unverified.
Metafields at checkout and on the Thank-you page
There is a documented asymmetry worth knowing: checkout targets can read metafields and write cart metafields through the Metafields API, while Thank-you page targets can read metafields but have no write access. If your plan depends on stamping something onto an order after payment, the depth of that mechanism belongs to our checkout extensibility guide.
The names you'll see in older guides
Key takeaway
Custom data has accumulated more vocabulary than most Shopify features, and a good half of the writing about it predates the current wording. Here is the translation table, so a five-year-old tutorial does not send you looking for a screen that no longer carries that name.
Old vocabulary, current meaning
| The term you will see | What it means today | Where you run into it |
|---|---|---|
| Private metafields | An API-only concept for app developers, with app-data metafields and app-reserved namespaces in its place | Developer posts and app documentation written before the change |
| Standard or Shopify-defined metafields | Standard definitions — prebuilt definitions you pick instead of inventing your own | Anywhere a guide lists ready-made fields such as ISBN or Care guide |
| Unstructured metafield | A value with no definition behind it, typically written by an app; it can be migrated onto a definition | Your own store, once an app has been writing fields for a while |
| Custom data | The admin section that holds both metafields and metaobjects, under Settings | The admin itself, and every current Help Center page |
| Category metafields | Attributes that come from the Standard Product Taxonomy; Shopify states their values use metaobjects and metaobject entries | The product page in the admin, under the product category |
| Namespace and key | The container and the field name — the pair that stops two apps colliding on the same key | Every definition screen, and every Liquid example you copy |
Shopify Help Center custom data terminology and metafields pages, plus Shopify.dev custom data documentation, read August 2026.
One entry on that table carries a real date rather than a rename. Shopify announced the PrivateMetafield deprecation on December 5, 2024, and the changelog entry is unusually direct about what replaces it.
Starting in API version 2025-01, PrivateMetafield will be removed from the GraphQL Admin API. Use app-data metafields instead.
For a merchant this is background rather than a task: PrivateMetafield was never a screen in your admin, so nothing on your side changed. It matters only when an app developer or an old guide invokes it — now you know which era they are writing from, and that ownership today is described as app-owned or merchant-owned, with Shopify-reserved and app-data as the two specialised cases.
Can you remove the app and keep the data?
Key takeaway
This is the question that decides whether the last three sections cost you anything, and it has a precise answer for one half and an honest blank for the other.
What actually exports
Before touching an app, get a copy of what exists. The routes differ by level, and the difference is documented.
| Data | In the product CSV? | The documented route |
|---|---|---|
| Product metafields | Yes | Once a product metafield is defined, Shopify includes it in product CSV exports as its own column |
| Variant metafields | No | Shopify directs you to the variant bulk editor, adding metafield columns there |
| Metaobject entries | No | The CSV documentation we read covers product metafields only; entries are reachable through the Admin API |
Product CSV import and export, Shopify Help Center, read August 2026.
Before you uninstall anything
The operative distinction is ownership. Values in a namespace you defined yourself are merchant-owned and live in your admin regardless of which app was used to type them in. Values an app wrote into its own reserved namespace are app-owned, and Shopify's uninstall page warns generally that "some apps store data that you can't recover after uninstalling" and tells you to export first, without naming metafields or namespaces.
So the instruction is unglamorous and firm: install the app on a development store, reproduce your field setup, and uninstall it there first. Twenty minutes of that answers a question the documentation does not, on data that does not matter, before you run the same action on a catalogue that does.
The same ownership question resurfaces if you ever leave the platform entirely, where custom data is one of the genuinely awkward parts of a Shopify exit — a theme travels badly and structured data travels worse, which we cover among the platform's real disadvantages and lock-in effects.
The Bottom Line
Key takeaway
Custom data is one of the few Shopify capabilities where the built-in answer is genuinely strong and the app market is genuinely noisy. If this is not the guide you needed — if the question is really about hiring, budget or a custom build — our Shopify development guide routes you to the right one in about a minute.
Frequently Asked Questions
Front-end developer specializing in Shopify since 2017. Experienced in building custom Liquid themes, optimizing storefront performance, and integrating third-party apps. Writes in-depth, data-driven e-commerce guides based on hands-on experience with real merchant stores.
What to Read Next
Shopify Online Store 2.0: Architecture, Sections, JSON Templates & When to Migrate
Shopify Online Store 2.0 explained — sections, JSON templates, metafields and dynamic sources, OS 2.0 vs Vintage themes, and the migration path that works.
Read articleWhat Is Shopify Liquid? Syntax, Use Cases & Limitations
Shopify Liquid in plain English — what the template language does, when you actually need it, real code examples, and what Liquid developers really cost.
Read articleShopify Product Configurator: App or Custom Build?
Native options, apps, or a custom build? Compare what each Shopify product configurator path costs, where apps break, and find your 2-year break-even.
Read article