Webflow Client-First Explained: Finsweet's Naming System

Webflow Client-First is a free class-naming system from Finsweet that gives every style in your project a human-readable, predictable name — so a class called padding-large does exactly what it says, and a custom class like team-member_photo tells you precisely where it lives. It splits your styles into two buckets: reusable utility classes (spacing, color, text size) you apply everywhere, and custom classes (underscore-prefixed) that belong to one component. The payoff is a site any teammate — or the next agency — can open and understand without a decoder ring.

That's the snippet answer. Now let me tell you why I actually care about this, because it's not really about naming.

Why a naming convention matters more than it sounds

Here's a scene you might recognize. A Webflow site starts clean. Beautiful style guide, tidy symbols, everyone's proud of it. Then marketing needs a landing page by Thursday, so someone forks a symbol and tweaks a class called div-block-47. A campaign needs a variant, so they fork it again. Six months later, shipping one page is a two-week ordeal involving three Slack threads and a prayer.

The site stopped being an asset and became a tax.

I'm not exaggerating for effect. Of the inherited Webflow projects we audit, roughly 60% need a partial refactor before they're safe to build on. Not because the people who built them were bad — usually the opposite — but because there was no shared rulebook for how a class gets named. And when there's no rule, entropy wins. Every developer invents their own shorthand, and by month nine the "style guide" is fiction and the project is a junk drawer. You open it looking for a stapler and find forty-three classes named Heading 2 copy copy bold (final).

A naming convention is the rulebook that stops that. Client-First is just the best-documented, most widely adopted version of one. Think of it like a shared kitchen: it's not that you can't cook without labeled containers, it's that the next person absolutely will if you don't.

Utility classes vs custom classes: the core split

Client-First's whole brain lives in one distinction, so get this part and you've got most of it.

Utility classes are reusable, single-purpose, and global. They do one thing across the entire site. margin-bottom-medium adds the same margin everywhere you drop it. text-color-blue paints text the same blue everywhere. You stack them like LEGO: text-size-large + text-weight-bold + text-color-white and you've styled a headline without writing a single bespoke class. Change the value once, and it updates everywhere — that's the magic, and also the thing to respect, because changing a global changes everything.

Custom classes are the opposite. They're specific to one component and they carry an underscore. pricing-card_title, team-member_photo, hero_button-wrapper. The underscore is the tell — it reads as "this belongs to the pricing-card thing." You use these when a utility stack can't get you there, or when the styling is genuinely one-of-a-kind.

The discipline is knowing which is which. Reach for utilities first; drop to a custom class only when the component truly needs its own identity. Most "junk drawer" sites I've seen got that way because every single element got its own custom class, so nothing was reusable and everything was a snowflake.

Folders, keywords, and how you actually find things

Naming is half of it. Finding is the other half, and this is where Client-First quietly earns its keep on a big project.

Webflow's class panel supports folder-style grouping when you name with a consistent structure. Client-First leans into that hard. Because every utility starts with a category keyword — padding-, margin-, text-, background-color- — they cluster together alphabetically and in the folders view. You type pad and every padding utility shows up. No hunting.

It sounds small. On a 12-page marketing site with a hundred-plus styles, it's the difference between a five-second lookup and the kind of archaeology that makes people give up and just fork the nearest div. The keyword-first naming isn't pedantry; it's making the search bar do the work your memory shouldn't have to.

Rem sizing, accessibility, and the part nobody reads

Client-First standardizes sizing on rem units instead of pixels, with an approved set of values. I know, the second I say "rem units" half of you started skimming. Stay with me, because this one's free credibility.

Rem sizing means your layout scales with the user's browser font setting. Someone bumps their default text size up because they'd rather not squint — a rem-based site respects that and scales gracefully. A pixel-locked site ignores them. That's a real accessibility win, and accessibility signals quietly feed your SEO, so it's the rare thing that's both the right call and the self-interested one. Client-First handing you a pre-approved rem scale means you're not eyeballing it every time.

When Client-First is honestly overkill

Now the part most "you must adopt this framework" posts skip, because committing to a side is harder than cheerleading.

Client-First is a system, and systems have a setup cost. For a five-page brochure site you're building solo and handing off once, the full convention can be more ceremony than the project earns. You'll spend time naming utilities you use twice. That's fine — admit it and move on.

Where it pays for itself, every time:

• A team touches the site. The moment more than one person edits styles, a shared rulebook stops being optional.
• You're handing it to a client or another agency. Readable class names are the handoff documentation.
• The site will grow. Templates and ad-hoc naming are great for week one and a tax by month nine. If this site needs to scale, pay the setup cost now or pay the refactor cost later — and the refactor is always more expensive.

Honestly? Even on smaller builds, some convention beats none. You don't have to adopt every rule in the Finsweet docs to get most of the benefit. Pick the utility-vs-custom split, the underscore rule, and keyword-first naming, and you've already dodged the junk drawer. The rest you can grow into.

That's the real pitch. Client-First isn't about looking professional — it's about whether the next person who opens your project (and there's always a next person, and sometimes it's you in eight months) can understand it without a meeting. We've cleaned up enough inherited junk drawers to build on a convention by default. If you'd rather not have a future refactor on the calendar, this is how you skip it.

If you've already got a project that's drifting into junk-drawer territory, our Webflow development agency team does exactly this kind of cleanup and rebuild — and it's worth reading the 10 Webflow development mistakes we see most, because half of them trace straight back to never having a naming system in the first place.

Frequently asked questions

Is Webflow Client-First free? Yes. Finsweet maintains Client-First as a free, open style system, including the documentation, a starter cloneable, and a global styles snippet. You can adopt as much or as little as fits your project — there's no license to buy.

What's the difference between a utility class and a custom class in Client-First? A utility class is reusable and global — it does one job everywhere (like margin-bottom-small). A custom class is specific to a single component and carries an underscore (like pricing-card_title). Reach for utilities first; use a custom class only when a component genuinely needs its own styling.

Do I have to use Client-First on every Webflow project? No, and you shouldn't pretend it's mandatory. For a small one-off brochure site you'll hand off once, the full system can be overkill. The moment a team edits the site, you're handing it to a client, or it needs to scale, a naming convention stops being optional — and Client-First is the best-documented one to standardize on.

Can I convert an existing Webflow site to Client-First? You can, but it's a refactor, not a rename. Retrofitting a convention onto a messy project means untangling forked symbols and one-off classes first — which is exactly the partial refactor we find roughly 60% of inherited Webflow projects need before they're safe to build on. It's usually worth it; just budget for it as real work, not a weekend cleanup.

Why does Client-First use rem units instead of pixels? Rem units scale with the user's browser font setting, so the layout respects people who bump up their default text size. That's an accessibility win pixels can't match, and it keeps sizing consistent across the project using an approved scale instead of one-off eyeballed values.