How to Put Allergen Information on a Digital Menu

Where the data actually comes from

Before any of this touches software, it has to come from somewhere. There are three sources and they are not equally good.

The third row is where errors enter. A chef will correctly tell you a dish contains no nuts and will not necessarily know the commercial stock base contains celery, because celery is not an ingredient anyone thinks about until it is on a list of fourteen.

So the first task is not data entry. It is collecting specification sheets for everything you buy in, and keeping them somewhere findable — because when a supplier reformulates, that document is the only evidence of what changed.

Record it against the item, not the menu

The single structural decision that determines whether this survives contact with a working kitchen.

A menu is a view: a selection of items arranged for a service, a season, or a location. The same dish appears on the lunch menu, the evening menu, and the room service card. If allergens are recorded on the menu, that dish carries three separate declarations that can disagree, and eventually will.

Recorded against the item, there is one declaration and every menu showing that dish shows the same thing. Correct it once and it is corrected everywhere. This is also what makes the data reusable for the printed copy some jurisdictions require you to offer alongside a digital disclosure.

Variations and modifiers, the case that breaks things

A burger has a gluten-free bun option. A salad comes with or without the dressing. A curry is available at three heat levels using two different pastes. Each of those is a different allergen profile hiding inside one menu item.

Three ways to handle it, in order of preference:

1. 1Model the variation as its own priced option with its own allergen set. This is correct and it is the most work.
2. 2Split into separate items where the difference is substantial. Two dishes with two declarations beats one dish with a footnote.
3. 3Declare the superset and say so in the description — "contains gluten unless ordered with the gluten-free bun". Acceptable for simple swaps; poor for anything with several combinations.

What does not work is declaring the base dish and leaving the modifier undeclared. A guest filtering for gluten sees the item excluded and never discovers the option that would have suited them, or worse, sees it included because the default was recorded and orders the wrong version.

Showing it to a guest

Three display conventions, each with a real trade-off.

Icons

Compact and scannable, and unreadable to anyone who does not already know the legend. They also fail for screen reader users unless each icon carries a text label. If you use icons, label them in text as well — which usually means the icons were not saving as much space as they appeared to.

Codes or numbers

Common on printed menus in the EU, where a dish is followed by a string of numbers keyed to a legend. It works on paper because space is scarce. On a phone it is a needless indirection: the screen can afford the words.

Plain words

"Contains: milk, wheat, celery." Longest, clearest, translatable, screen-reader friendly, and impossible to misread. On a digital menu this is almost always the right answer, and the fact that it looks less designed is not a good reason to avoid it.

Filtering versus labelling

A digital menu can do something paper cannot: let a guest hide everything containing an allergen. It is the most requested feature in this area and the one that carries the most risk.

The risk is what the absence communicates. A guest who filters for peanuts and sees eleven dishes reads that as a list of dishes that are safe for them. Your data says something narrower: eleven dishes whose recorded ingredients do not include peanuts. Cross-contamination, a modifier, a substituted ingredient, and an unrecorded supplier change all live in the gap between those two statements.

Labelling has the opposite property: it shows what is there and makes no claim about what is absent. It is weaker as a feature and stronger as a statement. Most venues should do both, with the filter honestly described.

AI-drafted allergens, and where the human goes

A model reading "slow-cooked lamb shoulder, celeriac purée, gremolata" can produce a plausible allergen list in a second. That is genuinely useful and it is not the answer.

It is useful because the blank-page problem is the reason allergen data does not get entered at all. A hundred items with a first-pass suggestion each is a review task; a hundred empty forms is a project nobody starts.

It is not the answer because the model is reading a description, not a recipe. It cannot know which stock base you buy, whether the fryer is shared, or that the gremolata recipe changed in March. It will be confidently right about the visible ingredients and silent about exactly the hidden ones that cause the errors.

Wording that stays honest

The wording around the data does real work, and the temptation is to write something reassuring rather than something true.

• Say what the data is: ingredient information recorded by the restaurant. Not "verified", not "certified", not "guaranteed".
• Direct anyone with a serious allergy to speak to staff. This is not a disclaimer to hide behind; it is the correct instruction, because a person can answer questions a menu cannot.
• Describe cross-contamination risk where it is real and specific — a shared fryer, a bakery kitchen — rather than as a blanket line on every dish. A precaution on everything is read as boilerplate and ignored.
• Do not use "gluten-free" as shorthand for "no wheat in the recipe". It is a regulated claim with a threshold in most markets.
• Date the information if you can. A guest who can see the menu was updated last week trusts it more than one that could be from any point in the last three years.

Keeping it true

The compliance question is answered once. "Is it still correct?" is answered forever, and that is the part a workflow has to carry.

1. 1Make the allergen fields part of creating an item, not an optional pass afterwards. Anything optional is skipped during service.
2. 2Re-check on supplier change. This is the trigger people miss, because the supplier does not announce a reformulation.
3. 3Re-check on recipe change, including the small ones. A butter finish added to a steak is a new declaration.
4. 4Run a scheduled full review — quarterly is a reasonable default — independent of any trigger.
5. 5Keep the printed copy on the same update trigger as the digital one, or it silently becomes a different document.

For what you are actually required to publish, see the EU's 14 allergens and US allergen disclosure after the ADDE Act. For how this workflow looks in our own product, see the nutrition and allergens feature.