Components in the CMS: the workarounds this finally retires
Until now, putting a real component inside a CMS rich text field meant an HTML embed, a character limit, and a script in page settings. Here is the workaround chain that produced, and which parts of it this launch actually removes.
Announced at Webflow Conf 2026: you can now drop a component straight into rich text, on the canvas or inside a CMS item, and configure that specific instance through props. Webflow's own framing is the agency one. Build a customer quote component once, hand it to the client's marketing team, and they add it to new posts by swapping the quote, the photo and the name.
That is accurate and it undersells what is being retired. The interesting part of this launch is not the feature, it is the workaround chain it makes unnecessary, and anybody who has shipped a content-heavy Webflow site has built that chain at least once.
What the workaround actually looked like
Rich text accepted an HTML embed and not much else. So a component inside an article became hand-written markup, and hand-written markup ran into a character ceiling. We hit exactly this building an image gallery for a client's project page in August 2026: the finished embed was about 13,600 characters against a 10,000-character limit on the Embed element, so it had to ship split in two.
The shape a single "component" ended up taking:
HTML Embed element markup + CSS ~5,400 chars
Page settings, before </body> script + data ~8,200 chars
Hidden Collection List data source, read from
data-* attributes at runtime
Three places to look, for one thing on the page. Nothing named
it as a unit, nothing versioned it, and a client editor could
delete half of it without the other half noticing.Check the exact ceiling for your own case rather than taking that number as current. Webflow's July 2024 plan update raised custom code limits to 50,000 characters on paid plans, and the Embed element's own limit is a separate thing from the page-level fields. The ceilings move, which is a recurring theme with Webflow's limits.
What a component actually gives you back
- One named thing instead of three anonymous fragments. It appears in the component list, so somebody who did not build it can find it.
- A design change applies to every instance at once, which hand-pasted embeds never did.
- Props per instance. Webflow's example is an AI-generated ROI calculator running different numbers on each comparison post while a single design change updates all of them.
- An editor cannot break it by deleting the wrong half, because there is no other half.
The handoff half, which matters more for agencies
Components in the CMS lands alongside three guardrails that only make sense together, and the combination is the actual agency story. Visibility controls decide which components a teammate with the Marketer role can even see in build mode, so the client gets a curated set rather than the whole catalogue. Slot restrictions specify which components are allowed in a given slot, so a component built for one layout stays in it. Default components for slots, arriving later this month, sets what a slot starts with, so a reserved area is not an empty mystery on every new post.
These guardrails apply whether your team is working directly in Webflow or agentically through the MCP, so a page template holds up no matter who is making the edit.
That last clause is the one worth reading twice. The guardrails constrain agents on the same terms as people. If you are handing a site to a client whose marketing team will be prompting an agent at it, the permissions model is now the thing standing between your build and a page rebuilt by something that has never seen your design system. That is a new consideration in a handoff document, and most handoff documents do not have it yet.
What it does not fix
A component placed in rich text is an instance, not a loop. If what you need inside an article is a gallery driven by a multi-image field, or a list that iterates over a collection, that is still not what this gives you. The gallery we split across two code fields was that shape, and it would still be that shape today, because the underlying constraint was never the embed. It was that a multi-image field cannot be iterated into custom markup.
So the honest summary is that this retires the workarounds for fixed components inside content, which is most of them, and leaves the collection-driven ones where they were. That is still a large improvement, and it is worth auditing an existing site for: every embed sitting in a rich text field is now a candidate for becoming a real component, and every one you convert is a thing your client can no longer break.
When you can use it
| Feature | Availability |
|---|---|
| Components in the CMS | Rolling out now, all customers next week |
| Visual editing for AI code components | All customers now |
| Component visibility controls, slot restrictions | Already shipped |
| Default components for slots | Later this month |
| Breakpoint canvas | Rolling out now, all customers next week |
| Style props for components | Later this year |
That last line is the contrast worth drawing. The headline product announcements from this conference are staged, gated or in preview, and the AEO agents are Enterprise-only. The builder-facing updates are the ones shipping to everybody this month, and they are the ones that change what a build looks like next week.

