
Webflow CMS vs Framer CMS: the ceilings that actually decide it
Both vendors publish their limits, and most comparisons quote numbers that are neither vendor's. Here are the figures from the source, the one Framer does not publish at all, and the differentiator that is now out of date.
Most Webflow versus Framer comparisons are written about the design tool, and the design tool is rarely what the decision turns on. Both draw. Both publish. What separates them on a real project is what happens when the content grows, and that is a question with published answers on both sides.
So this compares the ceilings, taken from each vendor's own pages rather than from other comparisons. That distinction earns its place here, because checking the sources turned up one number nobody publishes and one widely repeated claim that is no longer true.
The published limits, side by side
| Limit | Webflow | Framer |
|---|---|---|
| CMS collections, entry plan | 20 on CMS | 2 on Basic |
| CMS collections, upper plan | 40 on Business | 10 on Pro, 40 with add-ons |
| CMS items, entry plan | 2,000 on CMS | 1,000 on Basic |
| CMS items, ceiling | 20,000 on Business with add-ons | 40,000 on Pro with add-ons |
| Fields per collection | 60, or 30 on a legacy plan | Not published as a number |
| Reference fields | 10, or 5 on a legacy plan | Single and multi, both documented |
| Static pages | 300 on Business | 30 on Basic, 700 with add-ons |
The number Framer does not publish
Read Framer's pricing page for the Pro plan's CMS item allowance and it is not there. The page states 1,000 items against Basic, and it answers a question further down saying that with add-ons you can reach 40,000 items, 40 collections, 2 TB of bandwidth and 700 pages on Pro. Between those two figures, the base allowance that Pro actually includes is not given.
This matters because comparison articles state that number confidently, usually as 2,500, and it does not come from the pricing page. It may well be correct and it may have been correct once. Neither is the same as sourced. If the Pro base allowance is load-bearing for your project, ask Framer rather than trusting a table, including this one.
The differentiator that is out of date
The line that appears in comparison after comparison is that Framer has no multi-reference field, so relating one collection to many items in another needs a workaround. It is the single most repeated technical argument for choosing Webflow, and Framer's own developer documentation contradicts it.
From framer.com/developers/cms, read 4 September 2026:
collectionReference
A reference to an item in another Collection
multiCollectionReference
Multiple references to items in another Collection
Framer also ships an Academy lesson on CMS references and a
changelog entry announcing them. This is a documented feature,
not a workaround.There is still a real difference underneath it. Webflow's reference model is the older and deeper one, and its multi-reference behaviour in Collection lists is more established, which shows up on heavily interlinked structures rather than on a blog with tags. But the difference is now one of depth and maturity, not of presence, and a comparison that says the feature is missing is describing a version of Framer that no longer exists.
Webflow's answer depends on when you bought
One asymmetry makes this comparison harder than it looks. Framer's limits are the limits. Webflow's are the limits for plans bought since 15 July 2024, and a plan bought before that keeps its legacy entitlements: 30 fields per collection instead of 60, 5 references instead of 10, and in several cases a considerably larger bandwidth allowance than the current plan carries.
So a Webflow column in any comparison table is really two columns, and which one applies to you is a question about your billing history rather than your plan name. The detail is in why every article about Webflow's limits contradicts every other one, and the equivalent for Framer is in Framer's CMS limits.
When the ceiling actually decides it
Almost never, for a normal marketing site. A brochure site with a blog, a team page and a handful of service pages will not approach either platform's entry-plan ceiling, and choosing between them on item counts is answering a question the project does not ask.
- A catalogue. Products, courses, properties or vehicles, where the item count grows on its own and the ceiling is a date rather than a decision.
- A location set. City or service-area pages generated from a collection, where the row count is the point of the architecture.
- Deeply relational content. Anything where an item points at several others and those point back, which is where reference depth stops being a checkbox and starts being the model.
- A site with many static pages. Framer's 30 on Basic is the tightest number in the table and the one most likely to be hit by accident.
Pick the platform on the work, not the ceiling. Then check the ceiling, because the one case where it decides is the case where finding out late means rebuilding.
And check both numbers on the vendors' own pages before you commit, not in a comparison. This one included: it is dated for that reason, and one of the two claims it corrects had been repeated for long enough that it read as settled.

