Selling food online in the EU the information your storefront is legally required to show before checkout

Most food brands treat compliance as something that happens upstream. The supplier prints the label, the packaging carries the legally required text, and the storefront sells what is already compliant in the warehouse. For physical retail, that logic holds. Online, it breaks.

The EU’s Food Information to Consumers Regulation treats the product page the way it treats a physical label. The information a shopper would read on the back of the pack has to be readable on the website too, before they pay. That single shift changes what compliance is. It stops being a packaging question owned by your supplier and becomes a product-data question owned by whoever builds your catalog. And most catalogs were never modelled to carry it.

What does EU law actually require an online food store to show?

When you sell prepacked food online in the EU, the mandatory food information that appears on the physical label must also be available on your storefront, and most of it has to be present before the customer completes the purchase. Under the European Commission’s distance-selling rules for food, that mandatory information must appear on the material supporting the distance selling, such as the webpage, and be available before the purchase is concluded. The one routine exception is the date of minimum durability or the ‘use by’ date.

Three instruments sit behind that requirement. Regulation (EU) No 1169/2011, the Food Information to Consumers Regulation or FIC, governs what information must reach the consumer and how it is presented. Regulation (EC) No 178/2002, the General Food Law, establishes that food cannot be sold unless it is safe for consumption. Regulation (EC) No 852/2004 covers hygiene across the operation. Most published guidance stops at listing these three. The numbers matter far less than the operational consequence they share: the FIC Regulation extends the label onto your website, and that is where the work that nobody scopes upfront actually sits.

The rest of this comes down to three mechanisms. How the “distance selling” rule moves the label onto your webpage. What specifically counts as mandatory information once it gets there. And why the descriptions and images your marketing team writes are caught by the same rules. Each one lands in the same place: your product data.

The “distance selling” rule moves the label onto your webpage

In EU law, selling food online is a form of distance selling, and that classification is what pulls the label onto your storefront. The rule splits into two moments. Before the purchase is concluded, almost all of the mandatory food information has to be available on the webpage itself. At the moment of delivery, all of it has to be present, including the one particular allowed to wait.

That exception is the date of minimum durability or the ‘use by’ date. Everything else a shopper would find on the back of the pack has to be readable before they reach checkout. The reasoning is straightforward once you see it from the buyer’s side: someone ordering food they cannot physically pick up and turn over is entitled to the same information a shopper in a shop gets by reading the packaging. The webpage is standing in for the pack.

This is the point where “it’s all on the packaging” stops being a defence. The packaging is compliant. The shipment that arrives at the customer’s door is compliant. But the law treats the pre-purchase moment as its own obligation, and that moment happens entirely on your website, weeks before any physical pack reaches the buyer. A product page that shows a name, a price, a photo, and a paragraph of marketing copy is not carrying what the law expects a label to carry. The gap is invisible in a feature comparison and obvious in an audit.

Two practical consequences follow. The first is that the information cannot sit behind a cost or a barrier. It has to be accessible to the consumer at no supplementary charge, which rules out approaches like “email us for ingredients” or gating the detail behind an account. The second is that “available on the webpage” is doing real work as a phrase. Information that technically exists in your system but does not render on the product the customer is looking at does not meet the standard. The obligation is about what the buyer can actually read at the moment of decision, not what is stored somewhere in your admin.

That distinction between stored and displayed is where the operational problem starts, and it is the thread running through the rest of this article.

What counts as mandatory information, and where allergens sit

The FIC Regulation specifies a defined set of particulars that must reach the consumer for prepacked food. Read as a lawyer would, it is a list of disclosures. Read as the person building your catalog, it is a set of fields that every food product on your store has to carry and display. The translation between those two readings is the part most teams skip, and it is where compliance quietly becomes an architecture decision.

The fields every prepacked product page must carry

The mandatory particulars under Article 9 map almost one-to-one onto product data. Read as storefront fields rather than legal text, the list looks like this:

Listed out, none of these is surprising. The difficulty is not knowing the list. It is that a standard eCommerce product is modelled around a title, a price, a description, and an image, and this list asks for ten or more structured attributes that have to exist on every product, stay consistent as the catalog grows, and render reliably on the page the customer is reading. A generic product template has nowhere to put most of this except the description box, and the description box is exactly the wrong place for information that has to be accurate, comparable, and machine-readable.

Allergens: the field that cannot be free-text

Allergens are the particular where the gap between written down and structured costs the most. The regulation requires that the presence of any of the defined allergenic ingredients be made clear to the consumer, and online that disclosure has to be available before the purchase is concluded like the rest. The instinct is to handle it the way the packaging does, by emphasising allergens inside the ingredient text. On a webpage, that instinct creates a fragile dependency: the allergen information becomes trapped inside a free-text blob, where it cannot be filtered, cannot be checked programmatically across the catalog, and cannot be reused reliably in a basket summary, a filter, or a structured data feed.

A buyer with a severe allergy is not reading your ingredient paragraph for nuance. They are looking for a clear, unambiguous answer to a yes-or-no question, and the law expects that answer to be unambiguous. Treating allergens as a dedicated, structured field rather than a phrase inside a sentence is what makes that answer reliable at scale. It is also the field where the difference between a catalog that was designed for food and one that was adapted from a fashion template shows up first. The deeper mechanics of how allergen data should be structured, validated, and surfaced are their own subject, but the principle to carry here is simple: allergens are a field, not a sentence.

Your product descriptions and images are food information too

There is a quieter part of the regulation that catches teams who believe they have the mandatory fields covered. Food information is not limited to the formal label particulars. The way you describe and depict a product on the page is also regulated, because the law governs the impression the information creates, not just the boxes it fills. The copy your marketing team writes and the photographs your studio shoots are food information in the legal sense, and they have to be consistent with what the product actually is.

This matters because marketing and compliance pull in opposite directions by default. A description is written to make the product appealing. A serving suggestion photographs the product styled with ingredients that are not in the box. A phrase like “traditional” or a visual cue suggesting a region of origin can imply a claim the product cannot support. None of this is malicious, and most of it passes unnoticed until someone checks. But under the regulation, information that misleads the consumer about the nature, properties, or origin of the food is non-compliant regardless of where it appears, and a photo or a phrase can cross that line as easily as a mislabelled ingredient can.

The practical effect is that the regulated surface of your product page is larger than most teams assume. It is not just the structured fields from the previous section. It is the description, the imagery, the serving suggestions, and any origin cue, all of which have to stay true to the product and stay aligned with the structured data sitting alongside them. When the description says one thing and the ingredient field says another, you do not have a copywriting inconsistency. You have two conflicting pieces of food information on the same page, and the law does not treat the marketing one as exempt.

This is the third mechanism, and it points the same direction as the first two. The obligation is distributed across the entire product, the structured fields and the persuasive content alike, which means it cannot be solved by any single team in isolation. It has to be solved in the place where all of that content actually lives.

The real bottleneck: most catalogs were never modelled for this

Everything so far has pointed at the same place. The distance-selling rule puts the label on the page. The mandatory particulars ask for a dozen structured attributes per product. The descriptions and images widen the regulated surface further. None of that is hard to understand. What makes it hard to execute is that the constraint is not legal knowledge. It is the product-data model underneath your store, and that model is usually the last thing anyone examines.

Most eCommerce catalogs are built around a small, generous set of fields: a title, a price, a description, a handful of images, maybe a few tags. That structure is flexible enough to sell almost anything, which is exactly why it struggles with food. Food asks for allergens, a full ingredient list, a nutrition declaration expressed per a fixed quantity, net quantity, storage conditions, country of origin, and durability handling, all structured, all present on every product, all rendering correctly on the page the customer reads. A model designed for flexibility has no native home for any of this, so the information ends up where there is room for it: stuffed into the description, baked into an image, or held in a spreadsheet that never reaches the storefront at all.

Three failure patterns recur. The first is the free-text blob, where ingredients and allergens live inside a paragraph that cannot be queried, filtered, or validated across the catalog. The second is data trapped in images, where the nutrition table or allergen list is a photograph of the back of the pack, invisible to search, to filters, and to any structured data feed. The third is the most deceptive: fields that exist but do not display, where the information is sitting in your admin, technically captured, but never rendered on the product the customer is actually looking at. The first two are visibly incomplete. The third looks compliant from the inside and fails the one test the law cares about, which is what the buyer can read before they pay.

This is why the work is structural rather than editorial. Closing the gap is not a matter of writing better product copy. It is a matter of giving the catalog somewhere reliable to hold each mandatory particular as its own field, then making those fields render consistently across every product and every template. On Shopify Plus, that is what metafields and metaobjects exist to do: define structured, typed attributes for things the default product object does not anticipate, and reuse them cleanly across the catalog rather than retyping them into descriptions one product at a time. The platform mechanism is not the point in itself. The point is that the obligation only becomes manageable once the data model can express it natively.

This is the part of a build that rarely appears in a platform comparison and almost always appears in scoping. In Flatline’s experience structuring catalogs for regulated categories, the question that decides the timeline is not which fields the law requires. It is whether the data model can carry them on every product, render them in every market, and hold together as the catalog grows. When that foundation is set early, compliance becomes a property of the catalog. When it is retrofitted later, it becomes a recurring maintenance cost that compounds with every new product line. It’s exactly the kind of catalog architecture work our ecommerce agency scopes before a single product goes live.

Where the work actually sits, and how multi-market changes it

If the catalog is the bottleneck, then the intervention is upstream of design, copy, and even platform choice. It sits in the data layer, and it resolves into three moves that run in order.

1. Model the data layer before you populate it. Decide which mandatory particulars become structured fields, what type each one is, and how allergens and the nutrition declaration are represented, before a single product is loaded. This is the step that determines how much manual cleanup every future product requires. Getting it right once is cheap. Reverse-engineering it across a live catalog of hundreds of products is not.
   
   

2. Make the fields render where the customer decides. Captured data that does not display fails the requirement, so the structured fields have to surface on the product page itself, available before checkout, at no extra cost to the buyer. The test is not whether the information exists in your admin. It is whether the shopper can read it at the moment of purchase.
   
   

3. Add the per-market layer deliberately. Selling into more than one EU country does not change which particulars are mandatory, but it changes how they have to appear. Information has to be available in a language the consumer in the country of sale can understand, and origin and certain other details can vary by market. The structured-field approach is what makes this tractable, because a field can be translated and localised cleanly, while the same information buried in a description has to be rewritten and re-checked country by country.
   
   

That third move is where the cost compounds. A single-market store can sometimes survive an imperfect data model through manual effort. A multi-market one cannot, because every shortcut is multiplied by the number of countries you sell into. Running compliant food information across several EU markets from one store is far more an architecture question than a translation one, and it sits alongside the broader operational decisions involved in scaling international eCommerce from a single store.

None of this is the part of selling food online that brands expect to be difficult. The recipe, the sourcing, the brand, the photography are where the energy goes. But the platform-level decision that quietly governs how much compliance work you carry for the life of the store is the data model, which is one of the structural questions behind what Shopify Plus actually changes for food and beverage brands. Set it well and the obligation becomes invisible. Set it loosely and it becomes a tax on every product you ever add.

Frequently asked questions

Do I have to show allergens before checkout, or only on the packaging?

Before checkout. For prepacked food sold online in the EU, allergen information is part of the mandatory food information that has to be available on the webpage before the purchase is concluded, not only on the physical pack that arrives later. The packaging being compliant does not satisfy the online obligation, because the law treats the pre-purchase moment on your website as its own requirement.

What information is allowed to wait until delivery?

Only the date of minimum durability or the ‘use by’ date. Every other mandatory particular, including the ingredient list, allergens, net quantity, and the nutrition declaration, has to be available on the storefront before the customer completes the purchase. All particulars, including the date, must then be present at the moment of delivery.

Do non-prepacked or made-to-order foods follow the same rules?

Not identically. The full set of mandatory particulars applies to prepacked food. For non-prepacked food sold at a distance, a narrower set of requirements applies, with allergen information remaining the consistent obligation. If you sell made-to-order, bulk, or freshly packed items online, the specific particulars you must show differ, but the principle that the required information has to reach the consumer before purchase still holds.

Does this apply if I sell to another EU country from the Netherlands?

Yes. Selling into another EU country does not reduce the obligation, and it adds a language requirement: the mandatory information has to be available in a language the consumer in the country of sale can understand. Origin and certain other details can also vary by market. This is why structured, translatable fields scale across borders far better than information written into a product description.

Are product photos and descriptions really regulated?

Yes. Descriptions and images count as food information, and they must not mislead the consumer about the nature, properties, or origin of the product. A serving suggestion that includes ingredients not in the box, or a phrase or visual implying an origin the product cannot support, can be non-compliant even when the formal label fields are correct.

The reframe to carry

Selling food online in the EU is rarely held back by the law itself. The requirements are knowable, the list of mandatory particulars is finite, and the distance-selling rule is clear once you have read it. The hard part is structural. The FIC Regulation turns your product page into a label, and a label needs a place to put every piece of information it carries.

That place is your data model. When the catalog is built to hold allergens, ingredients, nutrition, origin, and the rest as structured fields that render on every product and translate across every market, compliance stops being a task and becomes a property of the store. When it is not, the same obligation reappears as manual work on every product you add, in every country you enter, for as long as the store exists.

The reframe worth keeping is simple. This is not a packaging problem your supplier solved. It is a product-data problem your storefront has to solve. If you are scoping a food store, or auditing one you already run, the most useful question is not which regulations apply. It is whether your catalog was ever modelled to carry what those regulations ask the page to show. Worth bringing to whoever owns your product data before the next product line goes live.