Webflow Multi-Reference Fields:
The Complete Guide

Multi-reference fields are Webflow's most powerful relationship type — and its most misunderstood. They let a single CMS item link to multiple items in another collection, enabling the many-to-many relationships that real content structures require. Blog posts with multiple tags. Events with multiple speakers. Products in multiple categories.

But multi-reference fields come with hard constraints that Webflow does not surface until you hit them. A 100-item cap per field. A maximum of five multi-reference fields per collection. Performance implications that compound as your content grows. Understanding these constraints before you architect your CMS is the difference between a structure that scales and one that requires a painful rebuild six months in.

This guide covers everything: what multi-reference fields are, how they compare to single references and option fields, every limit and its workaround, the most common patterns, and how Trellis handles multi-reference setup automatically.

What Multi-Reference Fields Actually Are

A multi-reference field creates a many-to-many relationship between two CMS collections. Unlike a single reference field — which links one item to exactly one item in another collection — a multi-reference field lets one item link to many.

In database terms, a single reference is a foreign key. A multi-reference is a junction table that Webflow manages for you behind the scenes. You do not see the junction table, but it exists — and its constraints are what create the limits you will encounter.

When you add a multi-reference field to a collection, Webflow creates a relationship picker in the CMS editor. Editors can search and select items from the referenced collection, and the selected items appear as a list. In the Designer, you bind a Collection List to the multi-reference field to display the related items — tags beneath a blog post, speakers on an event page, categories on a product card.

Multi-Reference vs Single Reference vs Option Field

Choosing the right relationship type is one of the most consequential CMS architecture decisions you will make. Here is when to use each.

Single Reference

Use a single reference when an item belongs to exactly one parent. A blog post has one author. A product belongs to one brand. A team member is in one department. The relationship is one-to-many: one author has many posts, but each post has one author.

Single references are simple, performant, and have no item limit. They should be your default choice unless you specifically need many-to-many.

Option Field

Use an option field when the choices are a fixed, short list that does not need its own CMS items. Status labels (Draft, Published, Archived), content types (Article, Video, Podcast), or priority levels (High, Medium, Low). Option fields are lightweight — they do not consume a collection slot, they do not create relationships, and they are fast to query.

The tradeoff: option values cannot have their own pages, images, descriptions, or metadata. If your "categories" need landing pages with unique hero images and descriptions, they need to be a collection — not option values. For a deeper comparison, see the Reference vs Option vs Multi-Ref guide.

Multi-Reference

Use multi-reference when the relationship is genuinely many-to-many and the related items need their own CMS presence. Blog posts and tags (a post has many tags, a tag appears on many posts). Events and speakers (an event has many speakers, a speaker appears at many events). Products and categories (a product belongs to many categories, a category contains many products).

Multi-reference is the right tool for these patterns. But it is also the most constrained field type in Webflow, so reach for it deliberately — not as a default. Learn more about multi-reference field specifics in the multi-reference field guide.

The 100-Item Limit

The constraint: Each multi-reference field can link to a maximum of 100 items. If a blog post references tags, that post can have at most 100 tags. If a category references products, that category can contain at most 100 products.

When it matters: For most forward-facing relationships, 100 is plenty. No blog post needs 100 tags. No event has 100 speakers. The limit rarely bites on the "outgoing" side of a relationship.

Where it becomes a problem is on the "incoming" or reverse side. Consider a recipe site. Each recipe references its ingredients — maybe 10 to 30 per recipe, well within the limit. But now consider the reverse: an ingredient page showing every recipe that uses it. "Butter" appears in hundreds of recipes. "Salt" appears in thousands. You will hit the 100-item ceiling on the ingredient side long before you run out of recipes.

The same pattern appears with tags on high-volume blogs, categories on large product catalogs, and locations on directory sites. Any collection where a single item could be referenced by more than 100 other items is at risk.

The workaround: Create a junction collection. Instead of a direct multi-reference between Recipes and Ingredients, create a "Recipe Ingredients" collection with two single reference fields — one pointing to Recipes, one pointing to Ingredients. Each junction item represents one relationship. There is no item limit on single references, so "Butter" can appear in 5,000 junction items without hitting a ceiling.

The cost: junction collections add structural complexity. You need nested collection lists in the Designer, your item count increases (each relationship is its own CMS item), and editorial management becomes more tedious. But for relationships that will exceed 100 items, this is the only reliable pattern within Webflow.

The 5 Multi-Reference Fields Per Collection Limit

The constraint: Each collection can have a maximum of five multi-reference fields. This is a hard cap — Webflow will not let you add a sixth.

When it matters: Five sounds generous until you model a real-world collection. A Case Studies collection might need multi-references for:

• Industries served
• Services provided
• Technologies used
• Team members involved
• Related case studies

That is exactly five — no room for a Tags relationship, a Clients reference, or a Testimonials connection. You are at the ceiling before the design phase is over.

E-commerce makes it worse. A Products collection might need: Categories, Tags, Colors, Sizes, and Related Products. Five fields, fully consumed. If you later need a "Compatible Accessories" or "Frequently Bought Together" relationship, you have no slots left.

The workaround: Consolidate relationships. Combine "Industries" and "Services" into a single "Tags" collection with a "Type" option field. Use one multi-reference instead of two, and filter by type in your collection lists. You lose some semantic clarity — "Tags" is less descriptive than "Industries" — but you free up a multi-reference slot.

Another approach: use junction collections (as described above) for some relationships. Junction collections use single reference fields, which do not count toward the 5-multi-reference limit. You trade multi-reference simplicity for reference field headroom.

Performance Implications

Multi-reference fields have performance characteristics that differ from other field types, and they compound as your content grows.

Page load: Each multi-reference field on a CMS template page requires Webflow to resolve the related items at publish time. A page with three multi-reference fields, each linking to 20 items, means Webflow resolves 60 relationships when generating that page. Multiply that by hundreds of pages in a collection and publish times increase noticeably.

Editor performance: The CMS editor loads all available items in the referenced collection when you open a multi-reference picker. If your Tags collection has 500 items, the picker loads all 500 every time an editor clicks the field. For large referenced collections, this creates noticeable lag.

Collection list nesting: Displaying multi-reference items in the Designer requires nested collection lists. Webflow allows a maximum nesting depth of five. If your page layout already uses two levels of collection list nesting, you have three levels left for multi-reference content. Complex pages with multiple multi-reference fields displayed in nested layouts can hit this ceiling.

The practical advice: Use multi-reference fields deliberately. Do not create them speculatively. If a relationship might not be displayed on the front-end, do not create the multi-reference field — manage it in your source data and sync only what the site needs.

Common Multi-Reference Patterns

Blog Posts and Tags

The most common multi-reference pattern. A "Blog Posts" collection multi-references a "Tags" collection. Each post can have multiple tags, and each tag page shows all posts with that tag. This works well as long as no single tag is applied to more than 100 posts — which is the threshold where you need to switch to a junction collection or archive older content.

Events and Speakers

An "Events" collection multi-references a "Speakers" collection. Each event has multiple speakers, and each speaker page lists their upcoming and past events. This pattern rarely hits the 100-item limit because even prolific speakers rarely appear at more than 100 events on a single site.

Products and Categories

A "Products" collection multi-references a "Categories" collection. A product can belong to multiple categories (a lamp is both "Lighting" and "Living Room"). This is where the 100-item limit often matters — popular categories like "Sale" or "New Arrivals" can easily exceed 100 products. Plan for junction collections if your catalog will grow past that threshold.

Courses and Instructors

An "Online Courses" collection multi-references an "Instructors" collection. Team-taught courses have multiple instructors, and each instructor page shows their course catalog. The same pattern applies to programs and faculty, workshops and facilitators, or classes and teachers.

The Companion Collection Workaround for Galleries

One of the most common reasons people reach for multi-reference fields is image galleries. Webflow has no native multi-image field — each image field holds exactly one image. So how do you give a product six photos?

Some people try using a multi-reference to a "Media" collection. This works for shared images (the same photo used across multiple products) but is awkward for item-specific galleries. The media items live in a shared pool, and every product's gallery images are visible to every other product in the multi-reference picker.

The better pattern: Create a companion "Gallery Images" collection with fields for Image, Alt Text, Sort Order, and a single reference back to the parent (e.g., Product). Each gallery image is its own CMS item, scoped to its parent via the reference field. Display them using a nested collection list filtered by the parent reference.

This companion collection pattern does not use a multi-reference field at all — it uses a single reference from the child to the parent. This means it does not count toward your 5-multi-reference limit, has no 100-item cap (a product can have as many gallery images as you want), and the images are properly scoped to their parent item.

The tradeoff is editorial friction. Adding images to a product means creating new items in the Gallery Images collection, setting the parent reference, and managing sort order manually. For content teams used to dragging images into a gallery widget, this is a significant workflow change.

How Trellis Handles Multi-Reference Setup

Multi-reference fields are where Webflow CMS architecture gets genuinely complex. You need to plan for limits, choose between multi-references and junction collections, manage companion collections for galleries, and keep within the 5-field-per-collection cap — all before your first piece of content is entered.

Trellis handles this automatically. When you describe your content structure — or connect an existing Airtable base — Trellis analyzes your relationships and makes the right architectural decisions:

• Relationships that fit within the 100-item cap become multi-reference fields
• Relationships likely to exceed 100 items automatically get junction collections
• Image galleries become companion collections with proper sort order and parent references
• If a collection would exceed 5 multi-reference fields, Trellis consolidates or restructures to stay within the limit

Your content lives in Airtable, where linked records have no item limit and there is no cap on the number of link fields per table. Trellis translates that flexible data model into Webflow's constrained structure — handling the workarounds invisibly so you never have to think about them.

Frequently Asked Questions

Can I increase the 100-item multi-reference limit?

No. The 100-item cap is a hard limit in Webflow across all plans. There is no upgrade, setting, or workaround within Webflow itself. The junction collection pattern is the standard way to exceed this limit.

Do multi-reference fields count toward the 60-field limit?

Yes. Each multi-reference field counts as one of your 60 fields per collection. Combined with the 5-multi-reference-per-collection cap, this means multi-reference fields are doubly constrained.

Can I sort items within a multi-reference field?

Yes, but only manually in the CMS editor. You can drag items to reorder them within the multi-reference picker. There is no way to sort multi-reference items automatically by a field value (like date or alphabetically). If you need automatic sorting, the companion collection pattern with a Sort Order field gives you more control.

Should I use multi-reference for navigation menus?

It depends. If your navigation items are CMS-driven and a page can appear in multiple menus, multi-reference makes sense. But for most sites, navigation is better handled with Webflow's static nav component or a dedicated "Navigation Items" collection with a single reference to its parent menu. Multi-reference adds complexity that navigation rarely needs.

What happens to multi-reference data when I delete a referenced item?

Webflow removes the deleted item from all multi-reference fields that linked to it. The relationship is cleaned up automatically. If a blog post referenced a tag that gets deleted, that tag simply disappears from the post's tag list. No broken references, no errors — the item is just gone.