Webflow Multi-Reference Fields: What They Are and 5 Ways to Use Them
Multi-reference fields unlock the most powerful Webflow CMS patterns. Here's what they are and 5 real-world uses with setup steps.
The webflow multi reference field is one of those features that most people underuse because the name is a little dry and the documentation is thin. Once you understand it, it unlocks the CMS patterns that separate a basic blog from a genuinely structured content site.
Short answer: a multi-reference field lets one CMS item link to many items in another Collection. A single-reference field links one post to one author. A multi-reference field links one post to five tags, or one case study to three services, or one team page to twelve contributors. If you’ve been fighting Webflow’s CMS structure to represent many-to-many relationships, this is the tool you’ve been missing.
This post walks through five real uses I’ve built across client sites, with field configuration for each, plus the gotchas that will trip you up if you don’t know they’re coming. If you want help architecting any of this for a specific project, get in touch.
What a Webflow multi-reference field actually is
In relational database terms, a multi-reference field is a many-to-many relationship. In plain Webflow terms, it’s a field type you can add to any Collection that points to any other Collection (or the same one) and allows multiple selections.
Here’s how the data model looks when you add tags to blog posts:
Collections
├── Blog Posts
│ ├── Title (plain text)
│ ├── Body (rich text)
│ └── Tags (multi-reference → Tags Collection) ← here
│
└── Tags
├── Tag Name (plain text)
└── Slug (auto-generated)
Each Blog Post row can now hold references to 1–20 Tag rows. On the template page, you bind a Collection List component to that multi-reference field and it renders each linked tag. Without the multi-reference field, you’d have to pick one tag per post (a single-reference), or hack around it with a plain text field of comma-separated values — which means no linking, no filtering, no CMS-connected output.
Compare the two field types side by side:
| Single-reference | Multi-reference | |
|---|---|---|
| Links to | 1 item in another Collection | 1–20 items in another Collection |
| Useful for | Post → primary author | Post → all tags |
| Filter capability | Filter by exact match | Filter by “contains this page” |
| Sort by field | Yes | No |
| Chainable in CMS | Yes | 1 level only |
Multi-reference was added to Webflow’s CMS specifically because teams building content sites kept running into the single-reference wall. Once you know when to reach for it, your collection architecture becomes much more expressive.
Use 1: Tags on blog posts (and outputting them)
This is the most common use and also the one where I see the most implementation mistakes. The setup is straightforward; the output binding trips people up.
| Config | Value |
|---|---|
| Field name | Tags |
| Field type | Multi-reference |
| Reference target | Tags Collection |
| Template binding | Collection List → Get items from: Tags (multi-ref field) |
In the Webflow Designer, here is the pattern that works:
- Add a
div.post-tagswrapper inside your Blog Post template. - Drag a Collection List component into that wrapper.
- In the Collection List settings, set the source to “Tags” — the multi-reference field on the current Blog Post, not the Tags Collection directly. This is the step people miss. If you bind to the Tags Collection directly, every post shows every tag, unsorted.
- Inside the Collection List item, add a text element and bind it to the Tag Name field.
- Style as pills, links, or plain labels.
The full Webflow blog setup guide covers how to structure the Tags Collection itself, including whether to add a color field (useful if you want colored category pills without custom code).
One nuance worth knowing: the Collection List bound to a multi-reference field inherits the 20-item display limit that applies to all Webflow Collection Lists. If a post somehow has more than 20 tags (rare, but possible if you’re migrating from another CMS), the remainder won’t render without a workaround.
Use 2: Team members on case studies
On client sites, case studies almost always involve more than one person — a lead designer, a developer, a strategist. A single-reference “primary author” field doesn’t capture the team. Multi-reference does.
| Config | Value |
|---|---|
| Field name | Team Members |
| Field type | Multi-reference |
| Reference target | Team Collection |
| Template binding | Collection List → Get items from: Team Members (multi-ref field) |
Collections
├── Case Studies
│ ├── Title
│ ├── Client
│ ├── Hero Image
│ └── Team Members (multi-reference → Team)
│
└── Team
├── Name
├── Role
└── Headshot (image)
On the case study template, drop a Collection List bound to the Team Members field and you get a rendered list of every contributor with their headshot and role. The team member data lives in one place — update someone’s title in the Team Collection and it updates across every case study they’re linked to.
This is also where keeping your Collections normalized pays off. If you had inline-entered team member names per case study, a rebrand would require editing dozens of items. With multi-reference, it’s one edit.
Use 3: Categories filtered by the current page
This is the pattern I reach for when building tag or category archive pages — pages that show all posts belonging to a given category. It uses multi-reference filtering natively in Webflow, with no JavaScript required.
| Config | Value |
|---|---|
| Field name | Categories |
| Field type | Multi-reference |
| Reference target | Categories Collection |
| Template binding | Collection List on Category template → Filter: Categories contains current Category |
The key is in the filter. On the Category template page, add a Collection List sourced from Blog Posts, then add a filter condition:
Filter: Categories | contains | Current Category Page
This is Webflow’s “items that contain this page” toggle — it resolves the reverse relationship automatically. The Category page for “Design” shows only posts tagged with “Design”, without any custom code.
This pattern scales to any taxonomy: topics on a podcast, services on a team member page, ingredients on a recipe. The filter logic is identical. The only constraint is the 1-level-deep chain limit — you can filter posts by category, but you can’t filter posts by the parent category of a category.
Use 4: Related posts (the hub-and-spoke pattern)
Manually curated “related posts” are a maintenance nightmare on any content site with more than 30 posts. The multi-reference approach makes them automatic and consistent.
The pattern: create a Topics Collection that acts as the hub. Every Blog Post references the Topics it covers. On the Blog Post template, you pull related posts by showing other posts that share at least one Topic with the current post.
| Config | Value |
|---|---|
| Field name | Topics |
| Field type | Multi-reference |
| Reference target | Topics Collection |
| Template binding | See pattern below |
Collections
├── Blog Posts
│ ├── Title
│ ├── Topics (multi-reference → Topics)
│ └── ...
│
└── Topics
├── Topic Name
└── Slug
On the Blog Post template, the “related posts” section is a Collection List sourced from Blog Posts, filtered by: “Topics contains [any topic from the current post’s Topics field].” In practice this means: show me other posts that are tagged with at least one of the same topics as the current post.
The spoke is the individual post. The hub is the Topic. Every post connects outward to the hub, and the hub connects back down to every other post tagged with it. This is the architecture behind any well-linked CMS site, and it’s also good for SEO — Webflow CMS limits explains where this pattern hits its ceiling and when to break it into separate Collections instead.
One caveat: you can’t sort the related posts by relevance (number of shared topics) natively in Webflow. They’ll sort by date or name. If relevance sorting matters for your use case, that’s a Finsweet Attributes job.
Use 5: Multi-author attribution
Collaborative content — co-written posts, roundups with multiple expert contributors, interview-style articles with a host and a guest — needs multi-author support. Single-reference only gets you one author per post. Multi-reference handles the rest.
| Config | Value |
|---|---|
| Field name | Authors |
| Field type | Multi-reference |
| Reference target | Authors Collection |
| Template binding | Collection List → Get items from: Authors (multi-ref field) |
Collections
├── Blog Posts
│ ├── Title
│ ├── Authors (multi-reference → Authors)
│ └── Primary Author (single-reference → Authors)
│
└── Authors
├── Name
├── Bio
├── Avatar (image)
└── Social Link (link)
I keep both a Primary Author (single-reference) and Authors (multi-reference) on posts. The single-reference drives the byline and author-sorted index views. The multi-reference field drives the contributor cards at the bottom of co-authored posts, where each author gets a bio card with avatar.
This dual-field approach is worth the extra field slot: sorting and filtering by single-reference is reliable; sorting by multi-reference is not supported natively, so you need the single-reference for any author-filtered views.
On the Author template page, you can flip this around and show all posts by that author using the same reverse-filter pattern from Use 3: Collection List of Blog Posts, filtered by “Authors contains current Author page.”
Gotchas: sort order, the 20-item limit, and performance
Multi-reference fields are powerful, but they come with a set of constraints that are easy to run into on a real project.
| Gotcha | Impact | Workaround |
|---|---|---|
| 20-item hard limit per field | Items beyond 20 silently don’t render | Restructure to a junction Collection or break into sub-categories |
| Cannot sort by multi-reference | No relevance or custom ordering | Add a manual sort-order number field; sort by that instead |
| 1-level chain depth only | Can’t traverse post → tag → related posts natively | Use Finsweet CMS Nest or Attributes for deeper traversal |
| Build time increases | ~2–5s extra per multi-reference field on large Collections | Expected cost; not user-facing. Acceptable for most projects |
| No aggregate filtering | Can’t filter “posts with 3+ tags” natively | Requires custom JS or Finsweet CMS Filter with scripting |
The build time note is worth expanding. Webflow resolves multi-reference fields at static build time, not request time. On a Collection with 500 items and three multi-reference fields, you’re generating a lot of rendered HTML per build. The site loads fast for visitors — it’s just the publish step that takes longer. On high-volume sites I’ve seen this add 10–20 seconds to publish time, which is a minor operational inconvenience, not a performance problem.
The sort order limitation catches more people than the 20-item limit. If you design a case study grid that should show featured items first, you can’t sort by a multi-reference field. You need a separate boolean or number field for sort order. Know this before selling a client on a filtering and sorting UI — the filtering is easy; the sorting requires a separate field.
Multi-reference fields are also opaque to Webflow’s CMS search. The referenced item’s name text is not indexed as part of the parent item’s searchable content. If a blog post should be findable by its tag name in search, duplicate the tag text into a plain text field or use a search solution that indexes rendered HTML.
Multi-reference fields do one thing that no other Webflow CMS feature replicates: they let your content items relate to each other in realistic ways. Real content isn’t flat. Posts have multiple authors. Products fit multiple categories. Case studies involve multiple services. The moment you model that properly with multi-reference fields, you stop fighting the CMS and start using it as a structural advantage.
Frequently asked questions
What is a Webflow multi-reference field?
A CMS field that lets one item reference multiple items in another Collection. Example: a blog post can have multiple tags, a case study can have multiple services. Single-reference allows only one linked item; multi-reference allows many.
Can I filter a Collection by multi-reference on a template page?
Yes — Webflow supports filtering a Collection List by the current template's multi-reference natively (the 'items that contain this page' setting). For more complex multi-reference filtering, use Finsweet CMS Filter.
How many items can a multi-reference field hold?
Technically 20 items per multi-reference field. That's an underrated limit — for posts tagged 20+ times or authors with 20+ collaborators, you need a different pattern or a workaround.
Can I sort items by multi-reference fields?
Not directly. Webflow doesn't let you sort a Collection List by a multi-reference field. Work around it with a sortable single field (e.g., a number 'sort order' field) or restructure to a single-reference relationship.
Do multi-reference fields slow down Webflow sites?
A little. Each multi-reference field adds render time because Webflow resolves the references at build. For a 500-post Collection with 3 multi-reference fields, expect a few seconds longer build time — not user-facing slowness.
Can multi-reference fields chain to other references?
Only 1 level deep natively. A post → its tags is fine. A post → its tags → other posts in those tags requires Finsweet Attributes or a custom solution. This is Webflow's biggest CMS limitation.
Keep reading