Webflow | Component Visibility Gives Designers More Library Control

Webflow is giving Designers more control over which components appear to teammates working in Build mode. Released on August 19, 2026, the new component visibility setting lets Designers hide selected components from people with the Marketer role, helping teams keep large component libraries focused on the elements marketers and clients actually need to use.


Webflow component visibility controls for Designers and Marketers

{getToc} $title={Table of Contents}

Webflow lets Designers simplify component libraries for Marketers


Not every component in a Webflow project needs to be available to every collaborator. Design systems can contain advanced layout structures, development-specific elements, internal components, and other building blocks that are useful to Designers but unnecessary for people focused primarily on assembling or editing content.


The new visibility control addresses that distinction directly. Anyone with the Designer role can toggle individual components so they remain available to Designers while being hidden from Marketers. When someone with the Marketer role opens the site in Build mode, those hidden components no longer appear in the Add panel.



Shared Libraries keep the same visibility rules downstream


The setting becomes more important when teams rely on Shared Libraries. If a component is hidden from Marketers and then distributed through a shared library, that visibility rule travels with the component. Sites using the library therefore inherit the same distinction between components intended for Designers and those intended for Marketers.


This can help larger teams maintain a more predictable library structure. Designers can continue building comprehensive systems with specialized components while reducing the risk that clients or marketing collaborators accidentally choose elements that require deeper design or implementation knowledge.


Entire component groups can be hidden at once


Webflow also supports visibility controls at the group level. Designers who want to hide several related components do not need to update every item individually. Group settings include a Hide all for Marketers option that applies the visibility rule across the complete group.


This is useful for libraries organized around internal systems, advanced layouts, experimental components, development helpers, or other categories that should remain available to the design team without becoming part of the everyday page-building interface used by marketers.


Why this matters for structured page-building workflows


Component libraries become harder to navigate as they grow. A system that works well for the people designing and maintaining a site can become overwhelming for collaborators who only need a smaller set of approved sections, cards, banners, or content modules.


Controlling component visibility gives teams another way to separate system complexity from everyday publishing. Instead of maintaining a second simplified library or relying entirely on naming conventions to signal which components should be avoided, Designers can now enforce that distinction directly through Webflow's interface.


REMEMBER: Hidden components remain part of the project and are still available to Designers. The visibility setting specifically controls whether Marketers see them in the Add panel while working in Build mode.{alertSuccess}

Daisuki's Take: What This Means for Web Designers


The strongest value here is governance rather than a new visual capability. A mature component system often contains more building blocks than every collaborator should reasonably need, and exposing everything can make a carefully designed library harder to use.


For web designers working with clients, marketing teams, or distributed organizations, selective visibility can make component libraries easier to scale. Designers keep the flexibility required to maintain the full system, while less technical collaborators receive a cleaner set of choices for everyday page building.


We would use this alongside clear component naming and documentation rather than as a replacement for them. Hiding unnecessary complexity improves the interface, but a strong shared library still benefits from predictable structure, clear responsibilities, and well-defined components for each type of collaborator.



Sources and Recommended Links