Class Naming Systems

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 written against the Webflow Designer as it was on 2026-10-28. Webflow is a hosted service without version numbers, so the guidance of the Webflow Way and the community systems described here is dated by what was published at that check date, and https://webflow.com/updates is where product changes are announced. Class naming is a convention, not a feature: Webflow accepts almost any name, so every rule below is a team agreement rather than something the Designer enforces. All of it can be practised on the free Starter Site plan inside a Starter Workspace, because classes exist on every plan.

In a hand-written stylesheet a class name lives in a text file, where it is searched, refactored and reviewed with ordinary tools. In Webflow the same name is a label in a small panel, typed once and then applied by clicking. That difference is why naming deserves its own page: the name is the main way anyone, including the person who created it six months earlier, understands what a class is for. This page explains what the Designer does with a name, the official guidance of Webflow, the main families of systems, and how names behave for components and CMS-driven pages.

The running example is the Fernbrook Gardens site, a fictitious botanical garden. The example follows the naming of a "visit card" that appears on the Home page, on the Visit page and, through a Collection, on one page for every garden section.

Why naming matters in a visual tool

Four properties of the Designer make naming more important than it looks.

  • Classes are shared by reference. A class is one rule applied to many elements, and the Style selectors panel shows a counter of how many elements use it. A vague name such as Div Block 12 gives no hint that changing it will touch sixty elements.

  • The panel is a search box. Classes are found by typing into the Style selectors panel, so names that start with a predictable word group together when they are listed alphabetically, and a name that cannot be guessed cannot be found.

  • The Navigator shows names. The Navigator panel labels an element by its class, so the name is also the table of contents of the page. Readable names turn the Navigator into an outline.

  • Several people edit the same site. With designers, content editors and developers in the same site (see Plans, Workspaces, Seats and Roles), a convention is what keeps the stylesheet understandable when nobody remembers who created what. Real-time collaboration makes the problem sharper because two people can create near-duplicates at the same time.

The cost of a bad name is paid later: duplicate classes with slightly different values, "mystery" classes nobody dares delete, combo classes stacked on top of one another and developers who cannot map a rule in the browser tools back to something in the Designer.

What Webflow does with a name

The Designer treats a typed class name as an identifier and publishes it as a CSS class selector. Three practical consequences follow.

  • The name becomes an HTML class attribute and a CSS selector, in the same form. A class typed as visit-card is published as the class attribute value visit-card and as the selector .visit-card in the site stylesheet, and the readable name of the Designer is therefore the same text that appears in the browser developer tools.

  • Names are normalised. The Designer turns a name typed with spaces into a hyphenated selector, so a name typed as Visit Card ends up as visit-card in the published CSS. The easiest way to confirm what a given name becomes is to publish and inspect the stylesheet, and the sensible policy is to type names that are already in their final form: lowercase words joined by hyphens, with an underscore where a convention calls for one.

  • Names are global. There is a single namespace per site. A class called card created in the Home page is the same card that exists on every other page, and a second class with the same name cannot be created; the Designer refuses with an "already exists" message when a rename collides with an existing class.

Source: Webflow Help Center: Style selectors panel

The Webflow Way guidance

The Webflow Way is Webflow’s own set of recommendations for building sites. Its section on styles and the Webflow University lesson on class naming describe three roles for a class, and the recommendations are the closest thing to an official convention.

Role What it is Naming guidance Fernbrook example

Base class

A reusable set of styles used by a subset of elements, sometimes across element types. It is the default way of styling.

A plain, readable name with no prefix. Keep it generic enough to stay useful when the layout changes, so prefer section to home-hero-section.

section, container, card, button

Combo class

A variation of one specific base class, added to the element on top of it.

Prefix with is- or has- and describe the variation. Webflow recommends stacking no more than 3 to 4 classes and the University lesson advises one or two combos per base class.

card with is-featured, button with is-secondary

Utility class

A class that does one narrow job such as spacing, alignment or colour, intended to be reused and stacked with other utilities.

Prefix with u- followed by a short description of the single style. Build utilities as standalone classes, not as combos.

u-padding-top-large, u-text-center

Three more pieces of advice recur across the Webflow Way and the University lessons.

  • Pick one style and keep it. The lesson says to avoid mixing dashes, underscores and camelCase, and to use prefixes consistently, so that the role of a class is visible at a glance.

  • Keep names short but descriptive. Over-abbreviated names cause confusion and duplicates because nobody can tell whether cs-ht and card-hdr are the same thing.

  • Use the vocabulary of the team or design system. If the designers say "card" and the developers say "tile", the class names will end up with both.

The worked example of the lesson, adapted to Fernbrook, is a section with three ticket-price cards:

<section class="section">
  <div class="container u-text-center">
    <div class="card">…Day pass…</div>
    <div class="card is-featured">…Annual pass…</div>
    <div class="card">…Family pass…</div>
  </div>
</section>

The same elements as the Designer shows them in the Navigator are Section, Container and three Card entries, and the second card carries the combo is-featured. The u-text-center utility is applied to the container so the cards inherit the alignment.

Source: Webflow University: Class naming

The cost of stacking

Webflow’s recommendation of at most 3 to 4 stacked classes exists because combos have two limits. The order in which classes are stacked on an element cannot be changed after the fact, and a combo class belongs to its base class: it only exists in combination with it. Stacking many combos therefore creates compound selectors such as .card.is-featured.is-wide.has-shadow that are hard to read and hard to override. The mechanics, the generated selectors and the specificity consequences are explained in Classes, Combo Classes and Selectors and, for the CSS rules behind them, in Selectors and Specificity.

Families of naming systems

Beyond the official guidance, several systems have grown in the Webflow community. They differ in how much they decide for you, and none of them is required. The comparison here is neutral: each system answers the same question (how do I name and organise classes so a team can predict them) with different trade-offs.

Utility-first

A utility-first approach styles elements by stacking many small single-purpose classes, such as u-padding-top-large u-text-center u-bg-light, instead of creating a class per component. In Webflow this has a specific cost and a specific benefit.

  • Benefit. Spacing and alignment are defined once, so changing the value of u-padding-top-large changes it everywhere, and few new classes are created for one-off variations.

  • Cost. The Style selectors panel shows a long list of classes on each element, and the order of the stack matters when two utilities set the same property. Webflow’s own guidance asks for utilities to be standalone classes rather than combo classes, so that they remain independent of a base class.

  • Variables reduce the need. Since variables arrived in the Designer, the values (sizes, colours) can be shared without a utility per value. Variables are described in Variables and Modes.

BEM-like naming

BEM (Block, Element, Modifier) names the independent component, the part of it and a variation. Webflow’s Designer does not support the double underscore and double hyphen of strict BEM in the same comfortable way as a hand-written stylesheet, and the Webflow Way uses a lighter version of the same idea:

BEM idea Webflow form Fernbrook example

Block

The base class of the component.

visit-card

Element

A part of the block, named with the block as prefix.

visit-card_title, visit-card_image

Modifier

A combo class, with the is- prefix.

visit-card with is-featured

The benefit is that the structure is readable from the name alone. The cost is longer names and, because a block and its elements are separate global classes, the temptation to restyle an element through a descendant instead of through its own class.

Client-First

Client-First is a naming and structure system built and managed by Finsweet, a Webflow agency, and published at https://finsweet.com/client-first. It is a community system, not a Webflow product, and the commercial component library Relume builds its components on it. At the check date the current release is Client-First v3, which is reorganised around Webflow variables. Its main rules are:

  • a custom class carries an underscore and belongs to one component, page or group: form_component, form_wrapper, nav_link. The underscore also makes a virtual folder in the Finsweet browser extension;

  • a utility class has no underscore and does one reusable job: padding-global, max-width-small, text-color-secondary. Utilities are global;

  • a combo class is a variant with the is- prefix added to a base class: button with is-brand;

  • variables are organised into five collections (Base, Theme, Typography, Layout and Sizes);

  • the aim is that a class name tells a reader what it is doing without abbreviations.

Applied to Fernbrook, the visit card would be named visit-card_component, visit-card_image, visit-card_title with the combo is-featured and spacing from utilities such as padding-bottom-medium.

Source: Client-First: Getting started

Webflow Flowkit

Flowkit is a modular CSS framework that Webflow documents on its developer site. It is used on sites generated by Webflow AI, where the generated style guide page is built with it. It provides utility classes, component patterns and variables, and the documentation describes the legacy Flowkit framework with v2 as the default documentation. Its conventions are precise and different from Client-First:

  • a hyphen joins the words of a name (rich-text) and starts combo modifiers (is-secondary, gap-small);

  • an underscore separates a component from its part (card_body, nav_logo), connects a utility property to its value (margin-top_small, z-index_2) and adds a breakpoint suffix to a utility (text-align_center_mobile);

  • is- marks a component modifier, and combo classes always follow a main class (button is-secondary);

  • responsive utilities use underscore suffixes (_tablet, _mobile-l, _mobile) and responsive combo classes use hyphen prefixes (tablet-, mobile-l-, mobile-).

A site generated by Webflow AI therefore arrives with Flowkit names, and a team that edits such a site is better served by learning that convention than by renaming the generated classes. The relationship to AI generation is described in AI Features and Credits.

Source: Webflow developer documentation: Flowkit

Other community systems

Lumos, Flowbase and many agency-specific conventions exist. Lumos is a framework that relies more on custom CSS in embedded blocks, and Flowbase uses a BEM-inspired scheme with global, custom and combo classes and advises keeping combo classes for minor adjustments. The pattern across them is the same: a prefix or separator marks the role of a class, and the system is documented so that a newcomer can learn it in an hour.

Comparing the systems

System Maintained by Component part Variant Utility Strength Weakness

Webflow Way

Webflow

Not prescribed; plain base class names

is-, has- prefix

u- prefix

Official, short, easy to adopt

Leaves component parts to the team

Client-First

Finsweet (community)

Underscore: nav_link

is- prefix

No underscore: padding-global

Large community, templates and training

Long names, many utilities

Flowkit

Webflow (developer docs)

Underscore: card_body

is- and hyphen modifiers

Property_value: margin-top_small

Fits Webflow AI output, responsive suffixes

Unusual separators

BEM-like (for example Flowbase)

Agencies, community

Underscore or double separator

Combo

Optional

Structure visible in the name

Names grow with nesting

Choosing a system

There is no objectively best system, and the useful questions are practical.

  1. Who will inherit the site? If a client or another agency will, a documented public system (Client-First or the Webflow Way) lowers the training cost.

  2. Does the site start from a template or a library? A Relume component pasted into the site brings Client-First names, and mixing two conventions in one site is the most common source of confusion. Components from kits created at different times can follow different conventions, so check what a pasted component uses before adding it.

  3. Is the site generated by Webflow AI? If so, it already uses Flowkit names.

  4. How big is the site? A five-page marketing site is well served by the short names of the Webflow Way. A site with hundreds of CMS-driven pages benefits from the discipline of a stricter system.

  5. Is there a design system in the Libraries panel? Components shared across sites need names that are stable and meaningful outside one site. See Shared Libraries.

Whichever system is chosen, write it down in one page that lists the prefixes, the separator and three examples. The page can live in the Fernbrook style guide, and the Designer’s style guide page is a good place to display the classes in use, a technique described in Building a Design System.

Naming for components

A component (see Components, Props, Slots and Variants) packages an element tree, its styles and its properties. Its names have two audiences, and both need care.

  • Component name. This is the name in the Components panel and the Navigator, and it is not a CSS class. Use the plain name of the thing, such as Visit Card, so people can find it by typing.

  • Class names inside the component. Classes are still global to the site, so the classes inside a component follow the site convention and, in systems that mark parts, carry the component name as a prefix: visit-card, visit-card_title. A class named only title inside the component would clash with the same word used elsewhere.

  • Variants. A component variant is a variation of the component with its own styles. Webflow lets a variant style an element with the same class as the base, so name variants after the intent (Featured) and keep the class names stable, instead of making a new class for each variant.

  • Slots and properties. Properties and slots are named in the component’s settings. Use short nouns (Title, Image, Badge) because they appear to content editors who edit the instance on the canvas, as described in Content Editing on the Canvas.

A short checklist helps when promoting a group of elements to a component:

  1. rename the generated classes (Div Block 4) to the system’s names before creating the component;

  2. keep one base class on the root element, and have the other classes describe parts;

  3. avoid classes that only make sense on one page, such as home-card, in a component that is meant to be reused;

  4. name variants and properties from the point of view of an editor.

Naming for CMS content

Classes cannot be generated from content, so classes and Collections are named independently, but they interact in three places.

  • Collection list elements. A Collection list wrapper, the list and the item each carry a class. The default generated names include Collection List Wrapper, Collection List and Collection Item, which are poor names for a site with many lists. Rename them after the Collection: events-list, events-list_item. See Collection Lists.

  • Template pages. The elements of a Collection template page are bound to fields of the item. Class names should describe the role (event-hero, event-details) and not the field they show, so that a field can be replaced without renaming the class. See Collection Template Pages.

  • Field values used as classes. The Designer cannot print a field into a class attribute, so a design that depends on a category colour is built with a combo class on a conditional element or with a custom attribute, a technique described in Custom Attributes and JavaScript.

  • Field and collection names. Fields have a name and a slug. Collection and field names are for people (Event date), and the slugs are used in the API and in URLs, so slugs follow the same lowercase, hyphenated style as classes. See Collections and Field Types.

Fernbrook’s events Collection illustrates the pairing. The Collection is called Events, the template page has the class event-hero, and the list on the Home page uses events-list with the combo is-compact when it is shown in the footer.

Renaming and cleaning classes

The Style selectors panel (opened from the panel icon or with the G shortcut) contains the tools for keeping names tidy.

  • Rename. Selecting a class and using the wrench icon lets the name be edited and confirmed. Renaming does not change the styles and does not remove the class from any element, because the class is a single record that elements refer to. The rename is applied everywhere the class is used on the site.

  • Search. The panel’s search field finds classes and tags by name, and it is the most direct reason to use predictable prefixes.

  • Find unused classes. A class that is not applied to any element shows a trash icon, and clicking it deletes the class. A broom icon in the top right of the panel lists all unused selectors, and removing them cleans the site in one action.

  • Check before cleaning. A class can look unused while it is applied only in a component state or through custom code that adds the class with JavaScript, so review the list before bulk deletion. A class that is referenced only in custom code is unused as far as the Designer knows.

Renaming a class that custom code selects by name (a script that looks for .visit-card) breaks that code silently. The code is not checked by the Designer, so search the custom code of the site and of its pages before renaming, as described in Custom Code in the Head, Footer and Embeds.

Source: Webflow Help Center: Style selectors panel

Migrating to a convention

Adopting a convention on a site that already has hundreds of classes is done in steps.

  1. Decide the system and write it down.

  2. In the Style selectors panel, rename the highest-use classes first, since the count identifies them.

  3. Merge duplicates: where two classes hold the same values, apply one to the elements and delete the other. A rename that collides with an existing name is refused, so merging is done by reapplying.

  4. Delete unused selectors with the broom.

  5. Add the convention to the style guide page, so that new classes follow it.

Naming and the generated code

The effect of naming is visible in the published HTML and CSS. For the Fernbrook visit card, named with the Webflow Way plus a part prefix, the Designer produces markup and a stylesheet like this:

<div class="visit-card is-featured">
  <img class="visit-card_image" src="https://cdn.prod.website-files.com/…/orchid-house.webp" alt="The orchid house" loading="lazy">
  <h3 class="visit-card_title">Orchid house</h3>
  <p class="visit-card_text">Open daily from 9:00 to 17:00.</p>
</div>
.visit-card { background-color: var(--brand--cream); padding: 24px; border-radius: 12px; }
.visit-card.is-featured { border: 2px solid var(--brand--leaf); }
.visit-card_title { font-size: 24px; margin: 0; }
.u-text-center { text-align: center; }

The second selector shows the compound form of a combo class, and the specificity of .visit-card.is-featured is higher than that of .visit-card, which is why the combo wins when both set the border. The exact CSS written for each Designer action is explained in the page on classes, and the specificity rules are covered in the HTML and CSS section of this site.

Source: The Webflow Way

A second reason to care about the names appears in the browser: the Designer-friendly name is the only link between the DOM and the Designer. A developer who inspects the page and finds the class div-block-12 can only guess what to search for, while a name such as visit-card_title can be searched in the Style selectors panel directly. For the Designer API, class names are also the way scripts and Designer Extensions find styles, as in the following sketch that lists the classes of the selected element:

import type {} from "@webflow/designer-extension-typings";

const element = await webflow.getSelectedElement();
if (element && element.styles) {
  const styles = await element.getStyles();
  for (const style of styles) {
    console.log(await style.getName());
  }
}

Source: Webflow Designer API: Introduction

"Title Case, no dashes" in context

The book Webflow by Example (Packt, 2021) suggests typing class names in Title Case without dashes, such as Visit Card, because the names are easier to read in the panel. The advice is practical for a single designer on a small project, and two things have changed or should be weighed.

  • The Designer normalises a name typed with spaces into a hyphenated selector, so the published class is not Visit Card but its hyphenated form. The readable form in the panel and the published form can therefore differ, and this makes a developer’s search in the browser harder than a name that is already visit-card.

  • Modern systems depend on separators and prefixes that carry meaning: the is- of a combo class, the u- of a utility, the underscore of a part. A rule of "no dashes" removes the tools used to show a role at a glance.

The advice remains useful in its spirit: choose names that read as words, not as codes. It is better applied as "write names that a colleague would understand", using the separators of the chosen system. The book’s examples also pre-date components, variables and the Style selectors panel as they exist now, so its naming for Symbols corresponds today to the component naming section above.

Common mistakes and pitfalls

  • Leaving default names. Div Block 7, Text Block 2 and Collection Item tell nobody anything. Rename a class when it is created.

  • Naming by appearance. big-blue-heading stops being true when the colour changes. Name by role (page-title) except in utilities, where the value is the point (u-text-center).

  • Naming by location. home-card becomes wrong when the card is reused on the Visit page. Name by what it is.

  • Mixing systems. Pasting a Client-First component into a site that follows the Webflow Way gives two conventions in one stylesheet. Rename on paste or choose one system for the whole site.

  • Combo class sprawl. Stacking is-wide, is-dark, has-shadow and is-small on one base class breaks the 3 to 4 recommendation and produces selectors that are hard to override. Create a new base class, or a component variant, when the variations multiply.

  • Renaming classes used by scripts. Check the custom code before renaming.

  • Using the same name for a class and a component. The class visit-card and the component Visit Card are different things; the confusion is avoided by treating the component name as a human label.

  • Duplicates by typo. visit-card and visit-crad are two classes. The panel’s search and the unused-class cleanup reveal them.

  • Names that contain private information. Class names are public in the published HTML. Do not put client names, internal ticket numbers or staging notes in them.

Security and accessibility notes

Class names are published in plain text, so they can be read by anyone who views the source. They are not a place for secrets, internal project names or comments. They also do not replace semantic HTML: a class called button on a div does not make it a button for assistive technology, and the correct element and tag are chosen in the Settings panel. Accessibility is covered in Accessibility.

Corrections to older tutorials

Ali Rushdan Tariq’s Webflow by Example (Packt, 2021) was written before Components, variables and the redesigned Style selectors panel. Its naming advice is a good instinct (readable, consistent names) but its tip about Title Case without dashes, the term "Symbols" for reusable elements and its absence of any convention for utilities or combo variants do not match the practice of 2026. Older tutorials also describe combo classes as an unlimited way to vary a base class, while Webflow’s current guidance asks for no more than 3 to 4 stacked classes, and many tutorials recommend creating a utility class for every value, which variables now make unnecessary for sizes and colours.

References