Shared Libraries

This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production.

This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages.

This page was checked on 2026-10-28 against the Webflow Help Center, Webflow University and the Webflow product updates. Webflow has no version numbers, so everything below describes the product on that date. Shared Libraries is a feature that is still being extended: assets and variable modes were added after the first release, a dashboard view for managing Libraries came later, and bulk updates arrived in 2026. The Help Center article that documents it is marked as beta. Plans are named by tier only, never by price; the section on availability explains why the sources disagree and where to look.

A single Webflow site holds its own components, variables, classes and assets. As soon as an organisation has more than one site, the same brand needs to appear on all of them, and copying a button from one project to another turns every future change into manual work. A Library solves this by packaging reusable design resources on one site, the source site, so that other sites in the same Workspace can install them and receive updates. It is the mechanism that turns components and variables from a per-site convenience into a design system shared by many sites. The next page, building a design system, shows how the pieces fit together; this page covers the sharing machinery.

The running example is Fernbrook Gardens, a fictitious botanical garden. Besides its main website it runs a small shop microsite for the greenhouse plant sale and a separate site for the annual spring festival. All three should use the same colours, the same typefaces, the same buttons and the same footer. The team therefore creates a fourth site, named "Fernbrook Design System", that holds only the shared resources, and installs that Library on the three public sites.

What a Library is

A Library is a snapshot of selected resources from a source site, published for the other sites of the same Workspace to install. According to the Help Center and the product updates, a Library can contain four kinds of resources.

Components: the reusable building blocks with their props, slots and style variants. A component keeps its structure and its styling when it is installed.
Variables: the design tokens (colour, size, font, percentage and others) together with their collections. Since the update that added shared variable modes, a collection keeps its modes, so a Day and Night theme or a set of breakpoint modes travels with the variables.
Assets: images, documents and animations such as Lottie and Rive files. A Library can share every asset of the source site or only the folders chosen in the asset settings. Assets were added after the first release, and they are added to an existing Library the next time an update is shared.
Layouts: reusable page or section layouts.

Fonts are not a separate resource type. A typeface used in the design system is reached through a font variable, so a Library carries it as a variable, and the font file itself, if it was uploaded, is an asset of the source site. The practical advice is to define the Fernbrook heading and body typefaces as variables in a "Typography" collection and to reference them everywhere, so that installing the Library brings the typefaces with it. Webflow’s hosted font catalogue and Adobe Fonts connections are site settings, not Library contents; each installing site must have access to the same font source. The typography and fonts page explains the font mechanisms.

A Library is not a copy of a whole site. Pages, CMS Collections, forms, interactions that are not part of a shared component and site settings do not travel. The Library is also tied to its source site: the installed resources keep a link to the site they came from, and that link is what makes updates possible.

The source site

Every Library has exactly one source site. Webflow recommends keeping that site separate from any site that visitors see, a dedicated "Design System" website that contains only the variables and components that make up the design system. There are three reasons.

Editing a shared component happens on the source site, so a dedicated site gives designers a safe place to work without touching a live page.
A style-guide page on the source site documents each component for the team, and it is not published to visitors.
The rule described later, that an installed site cannot share, means that a site which is both a design-system source and a consumer of another Library is not allowed. A dedicated source site avoids that conflict from the start.

The source site’s own plan matters for the Workspace as a whole, not for hosting: it can stay on the free Starter Site plan because it never needs a custom domain. The plan that gates the feature is the Workspace plan.

Creating a Library

Sharing happens from the Components panel or the Variables panel of the source site’s Designer. The steps are the same in outline from either panel.

Build the resources on the source site: create the components, the variable collections and the asset folders that belong in the design system. Give them clear names, because every installing site sees those names.
Open the Components or Variables panel and choose Manage libraries.
Choose to share the Library with the Workspace, name it, select the components, variable collections and layouts to include, and decide in the asset settings whether to share all assets or only some folders.
Confirm. The Library is now available for installation on every site of the same Workspace.

The Designer API has no endpoint that creates or shares a Library; sharing is a Designer action. What the Data API does let a script do is read the components of a site, which is useful for auditing what a source site currently contains.

# List the components of the Fernbrook design-system source site.
# WEBFLOW_API_TOKEN and SITE_ID are placeholders: never commit a real token.
curl --request GET \
  --url "https://api.webflow.com/v2/sites/$SITE_ID/components" \
  --header "Authorization: Bearer $WEBFLOW_API_TOKEN" \
  --header "accept: application/json"

Source: Data API: List Components

The same call with the official TypeScript SDK reads as follows. The scopes needed are the read scopes for components, as the authentication and scopes page explains.

import { WebflowClient } from "webflow-api";

// WEBFLOW_API_TOKEN is read from the environment; it is never hard-coded.
const webflow = new WebflowClient({ accessToken: process.env.WEBFLOW_API_TOKEN! });

async function auditFernbrookComponents(siteId: string): Promise<void> {
  const { components } = await webflow.components.list(siteId);
  for (const component of components ?? []) {
    console.log(`${component.group ?? "(no group)"} / ${component.name}`);
  }
}

auditFernbrookComponents("SITE_ID_PLACEHOLDER");

Source: Data API: List Components

Installing a Library

Any other site of the same Workspace can install a Library.

Open the site in the Designer and open the Components panel or the Variables panel.
Choose Manage libraries and find the Library under the Workspace’s shared Libraries.
Choose Install.

The Library’s components appear in the Components panel, its variable collections in the Variables panel, its assets in the Assets panel and its layouts where layouts are chosen. Installed components are instances of the source components: the structure is shared, an instance can still be given values through its props, and the styling comes from the shared variables and classes. The detailed behaviour of props, slots and variants is described on the components, props, slots and variants page. Installing does not publish anything: the site must still be published for visitors to see the new components.

Two consequences are worth remembering when installing the Fernbrook Library on the shop and festival sites. First, a site that installs a Library depends on it for the shared resources, so deleting or renaming a shared component on the source site shows up in the update that the installing sites receive. Second, the installing site can still own local resources of its own, for instance a festival-only banner component. Names that collide with shared ones are a source of confusion, so the Fernbrook team prefixes shared components with fg- and keeps local components unprefixed.

The diagram shows the key asymmetry: a Library flows one way, from the source site to the installing sites, and a change only reaches an installing site when that site accepts it.

Updating: share once, accept per site

When the design system changes, the Fernbrook designer edits the component or variable on the source site and then shares the update from Manage libraries. Sharing an update does not change any installing site by itself. It makes the new version available, and each installing site then sees an indicator that an update is waiting.

Open the installing site in the Designer. The Libraries entry shows that an update is available.
Open the update review. It lists the changes in sections, variables, images and files, so that the designer can see what would change before it does.
Choose Accept updates to apply the changes to the site, or Uninstall to remove the Library from the site.
Publish the site so that visitors receive the new version.

This design is deliberate: a shared change never goes live on a site until someone responsible for that site chooses to accept it, and the site is still published separately. For Fernbrook the web lead keeps the main site on the latest version, while the festival site, which is frozen between events, is left alone until the next season.

The Libraries dashboard at Workspace level gives an overview. It lists the Libraries of the Workspace, shows which installations are out of date and lets an administrator open the review for a site without visiting the site first. For a Workspace with many sites this is the quickest way to answer the question "which sites still run last year’s buttons?".

The review modal is also the place to decide that a site no longer wants the Library. Uninstalling removes the link to the source site. The Help Center does not describe in detail what happens to instances already placed on pages, so test uninstalling on a duplicate of the site before doing it on a live one, and take a site backup first (see backups and recovery).

Workspace scope and the rule that an installed site cannot share

Two rules bound what Libraries can do.

A Library lives inside one Workspace. It can be installed only on sites of the Workspace that owns the source site. A Library cannot be shared across Workspaces. An agency that builds sites for several clients, each in its own client Workspace, therefore cannot publish one Library to all of them; the options are to keep the sites in one Workspace, or to copy the resources by hand into each Workspace’s own source site. The guest and client-seat model described in plans, Workspaces, seats and roles lets an agency work inside a client’s Workspace, but it does not turn that Workspace’s Library into an agency-wide one.

A site that has installed a Library cannot itself be shared as a Library. A site is either a source or a consumer. The documented consequence is that a Library cannot depend on another Library: there is no layering such as a brand Library under a product Library. A design system that needs two levels has to be flattened into one source site, with the product-specific parts kept as local components on the product sites. Fernbrook has no need for layering, which is one more reason to keep the design-system site separate and untouched by installs.

Enterprise: bulk updates and auto-install

Enterprise Workspaces get two governance features on top of the manual flow.

Bulk update. Since a February 2026 release, a person with access can push an update from a source Library to several installing sites at once, without opening each site to accept it. The pusher chooses which sites receive each update, can push only to sites that the person is allowed to edit, and the push appears in the site activity logs. Sites still have to be republished before the change reaches visitors, and the announcement describes the feature as rolling out to Enterprise Workspaces over time, so confirm that it is present in the Workspace before relying on it. Bulk update does not remove the per-site review for other tiers; on every other tier the update is accepted site by site.

Auto-install. A Workspace Owner or Admin can set a Library to install by default. In the Workspace settings, under the Libraries & Templates section, the shared Libraries have an auto-install option, and an Enterprise Workspace can turn it on per Library. From then on every newly created site of the Workspace starts with that Library installed, so a new campaign site begins with the brand tokens and components already in place. Auto-install applies only when a new site is created. It does not touch existing sites, and a site created by duplicating another site does not receive it through this setting.

Together the two features cover the lifecycle at scale: auto-install makes the first install automatic, and bulk update makes later versions arrive without a per-site review. They also change the risk. A bulk push is a change to many live sites at once, so large organisations pair it with the approval and roles practice described in page branching, releases and approvals and with the governance tools of the Enterprise page.

Plan availability

Availability is stated differently by different official pages, so this section states what is consistent and what is not. All sources agree that sharing and installing are Workspace features and that the free Starter Workspace has to be upgraded before Libraries can be used. They disagree on exactly which paid tiers include the feature.

The Help Center article on Libraries lists the number of Libraries per Workspace tier. It shows one shared Library on Freelancer, Core and Growth, and an unlimited number on Agency and Enterprise.
Webflow University and some product updates name a narrower group of tiers, for example Growth, Agency and Enterprise.
Auto-install on new sites and bulk update are Enterprise only.

The plan matrix on the plans page records the feature as available on a paid Workspace plan with a re-check note for the same reason. In practice, before designing a multi-site system around Libraries, open the Libraries article and the pricing page on the day of decision and confirm the tier, and treat the number of Libraries per Workspace as a limit that matters: a tier that allows one Library means one design system per Workspace, so everything shared must live in one source site. Prices are intentionally not quoted here; see the pricing page.

For Fernbrook one Library is enough: one source site, one Library, three consuming sites.

Design guidance for a Library

A Library is only as useful as the discipline around it. The following practices come from the way the update flow works.

Share tokens before components. Components reference variables, so share the variable collections first and make sure the components use them rather than hard-coded values. A component styled with raw hex colours cannot follow a later colour change.
Keep modes in the Library. Day and Night, or high-contrast modes, belong to the variable collection, so every consuming site gets the same themes and applies them with the same mode switch.
Name for the consumer. Names, groups and descriptions are the documentation another designer sees in the panel. Use a short prefix, descriptive group names and consistent casing; the class naming systems page compares conventions.
Change shared components compatibly. Renaming a prop or removing a slot on the source site affects every consumer on its next accepted update. Add new props and variants rather than replacing existing ones, and retire old ones in a later update.
Read the review before accepting. The list of changes in the review shows the sections, variables and files that would change. A designer who accepts without reading cannot explain a visual regression afterwards.
Share assets on purpose. Share only the folders that the design system really needs, such as logos and brand illustrations, so that consuming sites do not inherit hundreds of unrelated files. See images and assets.
Test on a branch or a duplicate. Accept the update on a duplicate or staging copy first when the site is critical.

Pitfalls and limits

Cross-Workspace sharing is not available. A Library cannot cross a Workspace boundary, so design the Workspace layout with it in mind.
An installing site cannot be a source. Do not install a Library on the site you plan to share from. Create a clean source site and keep it that way.
Updates are not live until the site is published. Accepting an update, individually or by bulk push, changes the Designer; visitors see it after a publish.
The Library count depends on the tier. A tier that allows one Library forces all shared resources into one source site.
Auto-install is for new sites only. Existing and duplicated sites need a manual install or, on Enterprise, a bulk update after a manual first install.
Uninstall behaviour needs a test. The official text on what remains on the pages after uninstalling is thin, so rehearse it before using it on production sites.
Beta documentation. The Help Center article is marked as beta and the feature still receives additions. Compare the article with the product updates list before depending on a detail, and check product changes and deprecations for dated changes.
Fonts are not a Library resource of their own. Share them as font variables, and make sure each consuming site can load the same font files.

Correcting older advice

Older tutorials and the 2021 reference book Webflow by Example describe a Webflow in which reuse across projects was a manual job: components were called Symbols, they existed inside one project only, and the way to reuse one in another project was to copy and paste it, which produced a disconnected copy. Libraries did not exist. Advice from that period to "keep a master project and copy elements from it" is replaced by a source site and an installed Library, with update review, shared variables and shared assets. Likewise the idea that every client site must carry its own copy of the brand styles no longer holds inside one Workspace.