Webflow Components vs Symbols vs Classes: A Decision Guide
When to use Components, Symbols, and classes in Webflow — what each one does, tradeoffs, and the rules I follow on every project.
The webflow components vs symbols question has a short answer: use Components for almost everything that repeats with any variation, Symbols only for site chrome that never changes, and classes to handle styling everywhere. That covers 90% of the decisions. This guide covers the other 10% — where the lines blur, where each tool breaks down, and the exact rules I follow so I don’t have to re-decide the same question mid-project.
If you’re inheriting a site that was built before Components existed, it’s full of Symbols doing things Symbols were never designed to handle well. This guide will help you figure out what to migrate, what to leave, and how to do it without breaking live instances. Reach out if you need someone to work through this on an existing project.
The short answer: a decision tree
Before getting into how each tool works, here’s the flowchart collapsed into a table. Save this for when you’re standing in front of a blank canvas trying to remember which one to reach for.
| Situation | Use |
|---|---|
| Same visual style, different element (e.g. all H2s share a font) | Class |
| Same HTML block that appears 1–2 times with identical content (site header, footer) | Symbol |
| Same HTML block that appears 3+ times with variable content (cards, testimonials, buttons) | Component |
| Content managed by editors or driven by a database | CMS Collection |
| One-off section that appears once and never repeats | Just a class — no Symbol, no Component |
The last row matters. Over-componentizing is as costly as under-componentizing — you end up with a panel full of single-use Components nobody can find and a source file that bloats publish time for no reason.
Coming from Figma? The structures Figma calls components almost always become Webflow Components — not Symbols, not raw HTML. Covered in detail in Figma to Webflow handoff.
Classes: the foundation
Every Webflow site runs on classes whether you’re thinking about them or not. Classes are CSS: they describe how elements look. Nothing else. They carry no HTML structure, no content, and no relationship between instances. Change the class, every element using it repaints. Simple, powerful, and the right tool for everything that’s purely visual.
The mistake I see most often: developers who don’t name classes deliberately end up with a panel full of div-block-47, div-block-48-copy, and div-block-48-copy-2. Six months later, no one can tell what those do or what changes if you edit them. Good class naming is not a style preference — it’s what lets you maintain a Webflow site after you’ve shipped it.
I use a loose utility-first naming convention: layout classes describe structure (flex-row, grid-3col), component classes describe element and variant (card, card--featured, btn-primary), utility classes handle one-off overrides (mt-24, text-sm). The important thing is consistency, not which convention you pick. The Auto Layout to Webflow Flex translation post shows this in practice.
Where classes fall short: anything that involves reusing structure, not just style. If you need the same card layout — image, heading, tag, paragraph, link — on five different pages, creating classes for each element and rebuilding the HTML every time is error-prone and unsustainable. That’s the job of Symbols and Components.
Symbols: when they still make sense
Symbols are Webflow’s original “shared element” feature. Add a Symbol to a page, change it in one place, every instance on every page updates. That synchronization is the entire value proposition — and it’s also the limitation.
Symbols have no concept of per-instance overrides. If you put a Symbol on five pages and want each one to show a different headline, you can’t do that without breaking the synchronization. The only way to vary content in a Symbol is to convert it to an unlinked copy first, at which point it’s no longer a Symbol at all.
That makes Symbols genuinely useful for one category: site elements that are completely identical on every page. The site header, footer, a global announcement banner. These never vary — you want a single source of truth. Symbols are right for those.
Everything else? Components.
Webflow hasn’t deprecated Symbols and probably won’t. But the product direction is clear — every new reusability feature has gone into Components, not Symbols.
Components: what changed and why they win most of the time
Components do what Symbols do — one source, every instance updates — and add one crucial capability: properties. Properties let you expose specific values (text, images, links, visibility) that can be overridden per instance without touching the source.
That changes everything. Now a single Card Component can render as a featured post card, a sidebar card, and a pricing card, each with different headings, images, and CTAs, all sharing the same underlying HTML structure and CSS. Change the layout in the source, it propagates to every instance. Change the headline text in an instance, it stays scoped to that instance.
Here’s how the three tools compare at a feature level:
| Feature | Classes | Symbols | Components |
|---|---|---|---|
| Reuse CSS styles | Yes | No | No |
| Reuse HTML structure | No | Yes | Yes |
| Per-instance content overrides | N/A | No | Yes |
| Syncs changes across instances | N/A | Yes | Yes |
| Usable inside CMS templates | Yes | Yes | Yes (with caveats) |
| Exposed properties | N/A | No | Yes |
| Conditional visibility per instance | N/A | No | Yes (boolean property) |
| Nesting (Component inside Component) | N/A | No | Yes |
The nesting row is underrated. A Button Component can live inside a Card Component, which can live inside a Section Component. Change the Button design once, it propagates everywhere — across every card, every section, every page.
Properties: the 80/20 of reusable design
Properties are what elevate Components from “slightly better Symbols” to “a real design system primitive.” Webflow currently supports five property types:
| Property type | Use case |
|---|---|
| Text | Headings, labels, body copy, button text |
| Image | Hero images, card thumbnails, avatar photos |
| Link | Button hrefs, CTA destinations, card links |
| Boolean | Show/hide entire sections or optional elements |
| Color (CSS variable) | Accent color overrides per instance |
Text properties cover the most common use case by a wide margin. You set a Text property on a heading inside the Component source, expose it with a name, and then every instance gets an override field in the right panel. No source editing required — content editors can fill these in without touching the Designer.
The connection to CMS is worth naming here: properties let you bridge Components and CMS data. When you place a Component inside a CMS Collection template, you can bind a Component property to a CMS field. The card title comes from the CMS Title field, the image from the CMS Hero Image field. The Component handles the layout and styling; the CMS handles the data. That boundary — Component for design structure, CMS for content — is the cleanest architecture for any data-driven page. I cover how to think about that boundary in detail in Webflow CMS structure.
Component overrides and when they break
Components are not magic. They have a specific failure mode that will cost you time if you don’t know it.
When you override a property on an instance, Webflow stores that override against the specific element in the source that the property is bound to. If you later restructure the source — change the element the property points to, delete the element, or nest it inside a new wrapper — Webflow can lose the connection to existing overrides on instances.
Adding new elements to the source is safe. Removing or moving existing elements that have bound properties is the operation that creates breakage. Adding properties to an existing Component is safe. Removing a property breaks every instance that used it. Renaming a property does not break instances — Webflow tracks by internal ID, not display name.
Migrating Symbols to Components
No one-click convert exists. Here’s the workflow:
1. Audit first. Open the Symbols panel and list every Symbol on the site. Annotate each one: does this Symbol’s content ever vary across instances, or is it always the same? Headers, footers, nav bars — usually the same. Cards, CTA blocks, testimonial items — usually vary.
2. Build the Component first. Open a Symbol instance, duplicate the element tree, and use that as the starting structure for a new Component. Define properties for every value that varies across instances. Name them for content editors, not developers.
3. Replace instances page by page. Add the new Component to the page, fill in the properties with the values from the Symbol instance, confirm it renders correctly, then delete the Symbol instance. Don’t try to do all pages at once — test as you go.
4. Delete the Symbol when all instances are replaced. Webflow will warn you if there are still active instances. That warning is your last line of defense.
Timeline: a 10-page site with 5–6 Symbols being migrated to Components takes 2–3 hours if the new Component structures are clean. A 30-page site with deeply nested Symbols that have workarounds baked in takes a day.
The one case where I leave a Symbol as a Symbol: the site header and footer. They never vary, and converting them to Components would add complexity with no benefit.
The rules I follow on every project
Decisions I’d re-make on every project if I didn’t write them down.
- Classes for visual styling, nothing else. If I’m trying to reuse HTML structure, I don’t reach for classes — that’s Symbols or Components. Classes describe look. Structure gets a different tool.
- No Symbol except header and footer. Every other reusable element is a Component. This rule means I never have to debug Symbol variation workarounds or explain why the CTA block looks different on the pricing page.
- Component threshold is 3+ uses. If I’d build the same HTML structure two times or fewer, I don’t create a Component for it. The overhead of managing a Component source isn’t worth it for low-use structures. Three or more uses with variation: Component.
- Define properties before building instances. It’s much harder to add properties to a Component after instances exist than to plan them upfront. Before placing the first instance, define every value that will vary and create the property for it.
- Bind Component properties to CMS where the content is dynamic. If content comes from a Collection, it goes into the CMS — not into a Component property override filled in manually per page. Component properties are for design-time overrides, not content management.
- Nest Components intentionally. Button inside Card is fine. Section inside Section is usually a sign the Component boundary is wrong. Nesting more than 2 levels deep becomes hard to maintain quickly.
- Treat Component source restructures as breaking changes. Audit instances before and after any structural edit. Publish to staging, check affected pages, then push to production. Same rigor as a database migration.
If you’re working from Figma files, the Figma to Webflow handoff guide covers how to decide at the handoff stage which Figma components become Webflow Components, which become Symbols, and which are just classes.
Use classes for styling, Components for structure, and CMS for content. Symbols are for headers and footers only. Follow those four lines and you’ll avoid the maintenance problems I’ve watched compound on production Webflow sites.
Frequently asked questions
What's the difference between Webflow Symbols and Components?
Symbols are the legacy shared-element feature: change the source, every instance updates. Components are newer and add properties: you can override text, images, links per instance without breaking the component. Components replace Symbols for 95% of cases.
Should I still use Symbols in Webflow?
Only for pure layout blocks that never vary — site headers and footers. Anything with variable content (cards, buttons, testimonials) should be a Component. Webflow hasn't deprecated Symbols but the direction is clear.
Do Webflow Components support properties?
Yes. You can expose text, image, link, visibility, and boolean properties. Setting one on a Component lets you override that value per instance without touching the source. This is the killer feature vs Symbols.
How do I convert a Symbol to a Component in Webflow?
Not directly — there's no convert button. Best workflow: duplicate the Symbol's content to a new Component with properties defined, then replace Symbol instances with Component instances, then delete the Symbol. 2–3 hours for a 10-page site.
What's the class-vs-Component rule of thumb?
Classes style elements. Components reuse structure + style + content. If you'd put the same HTML structure in 3 places, make it a Component. If you'd only reuse the CSS rules, use a class.
Can Webflow Components break instances?
Yes — if you restructure the source in a way that removes elements with overrides, those overrides are lost. Always test after source changes on 2–3 instance pages before publishing.
Keep reading