A component is an element you build once and reuse everywhere. Figma keeps the original, called the main component, and every copy you drop into a file stays wired back to it. Change the original, and the copies change with it.

That link is the entire point. Without it you’re pasting a button around a file and hoping nobody nudges one of the copies by hand.

Figma shipped dedicated component properties (text, boolean, instance swap, and variant controls) at its Config conference in 2022. Before that, variants were the only real way to manage states.

What Is a Component in Figma?

Almost any layer qualifies. A button, an icon, a card, a page header you’ve already assembled. You select it, convert it, and Figma stores that version as the source of truth. Every copy placed after that is an instance.

Things worth converting early:

  • Buttons and form inputs
  • Navigation bars and menu items
  • Icons and badges
  • Cards, modals, and other repeated layout blocks

The idea isn’t unique to Figma. It mirrors any library of interface building blocks, just built into the canvas instead of bolted on.

You can start from a single shape, a group of layers, or a whole frame.

Watch the layers panel. The purple icon is how you know a layer has actually become a component and not just a tidy group.

Main Component vs Instance

The main component is the version you edit directly. It shows up with a filled purple diamond in the layers panel. Instances carry a hollow diamond instead, and you change them through overrides rather than editing them outright.

Figma’s 2025 regulatory filing put monthly active users past 13 million in a single quarter (Figma S-1, SEC filing, 2025). At that scale, the same nav item is sitting inside dozens of screens belonging to one team. The main-to-instance link is what keeps those dozens from quietly diverging.

Have you seen the latest Figma statistics?

Discover comprehensive Figma statistics including revenue growth, market share, user demographics, and funding data.

Check them out →

How Edits Propagate to Every Instance

Change the fill, the text, or the layout of the main component, and Figma pushes it out automatically.

Changes you make on an instance itself are overrides. They stay local to that one copy. Nothing travels back up to the source.

Deletion works the same way in reverse. Remove a layer from the main component and it vanishes from every instance, unless a given instance had already overridden that spot.

So: edit the original when the change needs to land everywhere. This is covered in more depth in the guide on editing a component in Figma.

When Should You Turn a Layer Into a Component?

Second time you use something is usually the moment. A one-off hero illustration rarely earns it. A button always does.

Strong candidates include buttons, form inputs, toggles, repeated cards or list items, modals and confirmation dialogs, and dropdown menus.

Something like a modal window appears across dozens of screens in a typical product, which makes it an obvious first pick. Same reasoning applies to dropdown menus.

Weaker candidates? A one-time illustration. A layout you’re still figuring out and will probably scrap by Friday.

Skipping this has a real cost, and it’s a slow one. Each duplicated copy drifts a little further with every manual edit. Nobody notices until a client points at two buttons that don’t match.

How Do You Create a Component in Figma?

Select what you want to reuse, then convert it. Cmd+Option+K on Mac, Ctrl+Alt+K on Windows.

  1. Design the element once, exactly how you want it to look by default
  2. Select the layer, frame, or grouped layers
  3. Press the keyboard shortcut, or right-click and choose Create Component
  4. Rename it right away, before it gets buried in the layers panel
  5. Check the Assets panel, where the new component should now appear

Step four matters more than it looks. “Component 47” is fine for about an hour.

There’s a walkthrough with screenshots in this guide on how to make components in Figma if seeing it helps more than reading it.

Worth memorizing the shortcuts early, too. The full shortcut reference pays for itself once components become daily work.

Single Layer vs Multiple Layers

A rectangle with text on top converts just as easily as a card with five nested layers inside it.

Single layers are quick and fine for icons or simple shapes, though they limit how much you can customize instances later. Most real components go the other way: group or frame the layers first, then convert the whole thing. That’s the standard path for buttons, cards, anything mixing text with a background.

Converting a frame keeps its layout settings intact, so padding and spacing carry into every instance you place afterward.

How Should You Name and Organize Components?

File them like folders. Broad category first, specific variant second.

Slash naming is the part most teams miss. Type “Button/Primary” and “Button/Secondary” and Figma groups both under a “Button” folder inside the Assets panel automatically.

  • Button / Primary
  • Button / Secondary
  • Icon / Arrow / Left
  • Card / Product

GitHub publishes its component library publicly in Figma’s Community section, organized on exactly this pattern.

Figma adoption now sits above 90% across every company-size bracket tracked, from small businesses through large enterprises (Ramp, October 2025). Which is why naming discipline stopped being optional. Twelve inconsistent names is annoying. Two hundred is unusable unless somebody planned the folder structure on day one.

Component descriptions are underused. A single sentence in that field tells the next designer what the thing is for, so they don’t have to open it and guess.

Naming, thumbnails, and folder structure get a longer breakdown in this guide to Figma component best practices.

What Are Component Properties and Variants?

Everything exposed in the properties panel counts as a component property: editable text, true or false toggles, swappable nested components, and grouped variants.

A variant is different. It bundles several versions of the same element, say the states of one button, into a single component set that shares a property.

Property TypeControlsTypical UseEditable Per Instance
TextEditable text layersButton labels, headingsYes
BooleanShow or hide a layerIcon visibility, badgesYes
Instance swapWhich nested component appearsIcon or avatar slotsYes
VariantWhich version of the set displaysButton state, size, themeYes

Figma introduced dedicated component properties at its Config conference in 2022, layered on top of the older variants system that came before it.

Text, Boolean, and Instance Swap Properties

Text properties let whoever’s editing an instance change the label without touching anything underneath it.

Boolean properties are a switch. One click shows or hides an icon, a badge, a helper line.

Instance swap goes further, letting a designer replace a nested icon or avatar with a different one from the same library while the surrounding layout holds together.

Design tokens increasingly sit behind the actual values these properties push around, which ties individual components back to whatever design system the team maintains. 84% of teams have adopted design tokens as of the latest count (Zeroheight, Design Systems Report 2025).

Setting those values up, plus naming conventions for the tokens themselves, is covered in this guide to Figma variables.

Building a Variant Set

Select two or more components representing different states of the same element, then combine them into a component set. Figma wraps them in a dashed purple frame and exposes a variant property, usually named “State” or “Size.”

  • Default, hover, and pressed states for a button
  • Small, medium, and large sizes for the same icon
  • Light and dark theme variants for a card

These sets balloon quickly, and there’s a real ceiling. Figma’s community team has flagged performance problems once a single component set passes roughly 1,000 variants, tied to the browser’s per-tab memory limits (Figma Community forum, 2024).

Past that point, splitting a bloated set into two or three smaller components beats cramming everything into one.

The combine, rename, and property-assignment sequence is laid out step by step in this walkthrough on creating variants in Figma.

How Do Nested Components Work?

Nesting is one component placed inside another. An arrow icon sitting inside a button, for example.

The outer component treats the inner one as a regular instance, so it inherits the same override and swap behavior any standalone instance would have.

You see it constantly: an icon inside a button, an avatar inside a user card, a badge inside a navigation item.

This layering is close to atomic design thinking, where small pieces combine into larger ones and those combine into full page sections.

Nested components lean hard on layout settings to stay tidy as content changes length. Auto layout holds the gap between an icon and its label steady whether the label is one word or six.

Overriding a Nested Instance

Click into a nested instance and its properties open up, same as any top-level one. Swap the icon, recolor it, hide it, all without leaving the parent button.

The catch is that overrides on a deeply nested instance can vanish if the parent’s structure changes much, because Figma matches overrides by layer position rather than by name.

Two or three levels deep is about where this stays predictable. Beyond that, tracking which override lives where gets genuinely hard.

How Do Instance Overrides Work?

An override is any change made directly on an instance that differs from its main component, without severing the link between them. Text edits, fill swaps, resized icons, toggled booleans, all of it.

Overrides that survive a library update include text you typed into an instance, color and fill changes applied to it, visibility toggles on nested layers, and nested components you swapped out.

Structural changes made only to the main component (adding a new layer, say) won’t retroactively appear inside instances that already overrode that same spot.

Resetting an Instance to the Main Component

Right-click an instance and choose Reset all changes. Every override strips back to the main component’s default state.

It works at the layer level too. Select one overridden layer inside an instance, reset just that, and everything else stays as it was.

Design system maintainers use this constantly during audits. A full reset shows instantly how far an instance has wandered from spec.

Swapping One Instance for Another

Right-click, choose Swap instance, and point the layer at a completely different component in the same library. No deleting, no re-placing.

Position, constraints, and any prototype connections attached to that layer stay put. Only the underlying reference changes.

Typical reasons to do it: replacing an old button style with its updated version, switching a placeholder icon for the final one late in a project, or migrating instances off a deprecated component.

Don’t confuse this with an instance swap property. A manual swap works on any instance whether or not somebody defined a slot for it.

When Should You Detach an Instance?

Detaching cuts the link permanently. What’s left stops being an instance at all and becomes a plain group of shapes and text, treated like any other artwork in the file.

The upside is freedom. You can restructure layers however a one-off design needs, and no future library update will reshape something you made custom on purpose.

The downside is heavier. You lose every future update from the main component, and there’s no path back: reattaching means deleting the detached copy and dragging in a fresh instance. Audits get harder too, because detached elements no longer register as instances anywhere.

Salesforce found this out the hard way. An internal Figma audit of its Lightning Design System turned up thousands of detached instances that had quietly stopped receiving design system updates.

Figma has been chipping away at the reasons people detach in the first place. It started rolling out a feature called Slots in open beta on March 5, 2026, which lets designers swap content inside an instance, like an icon or a menu item, without detaching (Figma Community forum, product update, 2026).

Detach when a design is genuinely one-off and will never need an update again. If you just want flexible content inside an otherwise standard component, reach for Slots or an instance swap property first.

How Do You Publish and Share a Component Library?

Publishing turns a file full of local components into a shared library other files can enable and pull from. Open the Assets panel, click the library icon, hit Publish.

  1. Build and finalize components in a dedicated library file
  2. Open the Assets panel and select the library icon
  3. Review the list of new and modified components before publishing
  4. Add a short version note describing what changed
  5. Click Publish, then enable the library inside any file that needs it

The version note takes ten seconds and saves someone a confused Slack message three weeks later.

Team Library vs Local Components

Local components exist only inside the file where they were made. That’s the whole scope.

A team library gets published once, then enabled across as many files as you want, and every consuming file gets a notification when the source changes.

One design file can pull from several team libraries at once. That’s normal once icons, typography, and product components have been split into separate library files.

Plan Requirements for Publishing

Team libraries aren’t on every plan.

  • Starter (free): team libraries are not available at all (Figma Community forum, Figma staff reply, 2025)
  • Professional: $16 per full seat per month, billed annually, the entry point for team-wide libraries (Figma pricing page, 2026)
  • Organization: $55 per full seat per month, adds design system analytics on top of publishing (Figma pricing page, 2026)

Budget for the seat type as well. A Dev seat can inspect a published library in Dev Mode but can’t publish new components to it.

How Do Figma Components Connect to Code?

Two features carry a component’s structure into a codebase. Dev Mode inspects what already exists. Code Connect maps a component directly to the production code that implements it.

Dev Mode Inspection

Switch a file into Dev Mode, select any instance, and its spacing, colors, typography, and bound variables all show up in one panel.

You get exact spacing and sizing values ready to copy as CSS, plus a view of which design tokens or variables drive a given property, plus auto-generated snippets in a handful of common frameworks.

Those snippets are a starting point, not production code. That gap is precisely what Code Connect exists to close.

The full inspection workflow, including how to read the panel on a nested component, is in this Dev Mode guide.

Code Connect Mapping

Code Connect swaps Figma’s generic snippet for the actual component code pulled from a connected repository. It supports React, React Native, SwiftUI, Jetpack Compose, and HTML-based frameworks like Vue and Angular.

Peloton, the connected fitness company, paired Figma’s Dev Mode with a 24-mode variable system across its design libraries and cut design-to-development handoff time by 5x, including trimming manual design inspection from 15 minutes down to three, with its engineering team now exploring Code Connect as the next step (Figma customer case study).

Code Connect needs an Organization or Enterprise plan with a full Design or Dev Mode seat. The wider handoff workflow it slots into is mapped out in this guide to Figma developer handoff.

How Do Components Fit Into a Larger Design System?

A Figma library covers the design half. Documentation, code implementation, and governance are the rest, and they’re usually where things fall apart.

Dedicated ownership of all of it is becoming standard. 79% of teams now have a dedicated design system team, up from 72% the year before (Zeroheight, Design Systems Report 2025).

ToolPrimary PurposeSyncs With CodeBest Team Size
Figma libraryComponent design and reuseVia Code ConnectAny size
StorybookIsolated component developmentNative, built for codeTeams with engineers
ZeroheightCross-tool documentationEmbeds live code blocksMixed design and engineering teams

Atomic Design Layering

Atomic design sorts interface pieces into atoms, molecules, organisms, templates, and pages, the same layers most discussions of design system components use.

Mapped onto Figma, an atom is a single button, input, or icon component. A molecule is something like a search bar built from an input and a button nested together. An organism is a full navigation bar combining several molecules.

Nesting, covered earlier, is the mechanical feature that makes any of this layering possible inside Figma.

Storybook is still the most common code-side companion to a Figma library, common enough that it anchors the “syncs with code” column above.

Shopify’s Polaris and IBM’s Carbon Design System both publish their libraries this way, and both turn up regularly on lists of the best design systems available publicly.

When Should You Not Use a Component?

Skip it for anything that will exist exactly once. A single campaign landing page. A one-time illustration. Naming, documenting, and maintaining a component only pays off through reuse, and if there’s no reuse, you’ve just added overhead.

Cases where a component actively gets in the way:

  • Highly experimental layouts that change shape every few hours
  • Marketing pages with heavy custom art direction rather than shared UI patterns
  • Extremely early prototypes where speed matters more than structure

Components built on rigid layout rules break in ways that are easy to miss, too. Drop one into a frame with conflicting sizing settings and the content squishes or overlaps silently. No error, no warning.

And plenty of component libraries fail for reasons that have nothing to do with Figma’s mechanics. 56% of design system teams point to staffing, not tooling, as their single biggest challenge, ahead of leadership buy-in or documentation gaps (Zeroheight, Design Systems Report 2026).

A perfectly built library with nobody maintaining it goes stale the same way a duplicated layer does. It just takes longer.

FAQ on How To Use Components In Figma

How Is a Component Different From a Frame or a Group?

A frame is a layout container. A group bundles layers together and stops there.

Neither one carries the link between a main component and its instances, so edits made to one copy never reach the others the way a real component does.

What Happens to Instances if the Main Component Gets Deleted?

They survive, but they detach from the deleted source immediately. Each one keeps the appearance it had, minus any future updates.

Figma warns you before deletion when a component still has live instances, which gives you a chance to swap them first.

Can an Instance Be Converted Back Into a Main Component?

Not directly. There’s no command that promotes an instance to main-component status.

The workaround is detaching the instance, then converting that detached copy into a new component. It starts its own separate instance chain from zero.

Can Components Be Used on Figma’s Free Plan?

Yes, locally. The Starter plan lets anyone create components and instances inside a single file at no cost.

What’s blocked is publishing a team library, so those components can’t be shared or enabled across separate files without upgrading.

How Do Figma Components Compare to Sketch Symbols or Adobe XD Components?

All three link a master element to reusable copies, so the core idea travels. Sketch calls its version a symbol. Adobe XD uses the word component too.

Figma’s browser-based library and variant system make cross-file sharing easier to manage.

Where Does How To Use Components In Figma Break Down?

It breaks down once a library outgrows a single maintainer. Consistency depends on somebody reviewing every new component and variant before it lands in a shared file that other designers are already pulling from.

16% of design systems still run on exactly one person maintaining the whole library, according to Zeroheight’s Design Systems Report 2026. That’s the threshold where review queues start slipping.

Order matters more than speed here. Naming and property structure come first. Variant sets and instance behavior second. Library publishing and code handoff after that.

Jumping ahead to publishing before naming has settled buys you a fast week and rework across every consuming file later.

Turning a single file into a documented, versioned system is the next real step, and it’s covered in this guide on creating a design system in Figma.