Editing a main component and editing one of its instances feel identical while you’re doing them. The results are not remotely the same. Touch the main component and every instance in the file shifts with it, along with every library subscribed to that file. Touch an instance and you’ve changed exactly one copy.
Teams working out of a shared library depend on the first behavior. Buttons, cards, input fields stay consistent across forty screens because there is one source and everything else points at it.
The properties doing most of the work here (boolean, instance swap, text) landed at Config in May 2022 (Figma, Config 2022).
What Does Editing a Component in Figma Mean?
The main component is the master. Every instance in the file references it, and a change to a fill, a text style, or a nested icon inside that master travels outward to all of them at once.
Nothing else in Figma behaves quite like that.
You can spot a main component by the purple diamond in the layers panel. Instances get a different marker.
Worth being clear about what doesn’t count. A frame you copied and pasted by hand is just a frame. An instance isn’t a component either, it’s a reference carrying overrides on top. And a detached shape already cut its link, so it’s on its own now.
Figma, co-founded by Dylan Field in 2012, built this one-to-many relationship into the core of how components work.
Sketch had a comparable mechanism years earlier. Edit a master symbol there and every instance updates, no plugin required.
Teams leaning on a shared component library are usually running a design system, which echoes the same small-pieces-first thinking behind atomic design.
Have you seen the latest Figma statistics?
Discover comprehensive Figma statistics including revenue growth, market share, user demographics, and funding data.
Check them out →Component Editing vs Instance Editing vs Detaching
Overriding an instance and detaching one both feel like editing. Only one of them keeps the link intact.
| Action | Affects instances | Reversible | Best use case |
|---|---|---|---|
| Edit main component | All instances, everywhere | Yes, edit again anytime | Design-wide changes |
| Override instance | Only that instance | Yes, reset override | One-off content swap |
| Detach instance | None, link removed | No, except an immediate undo | Permanent custom variation |
Detaching turns the instance into a plain frame. Same layers, no memory of where it came from.
Figma’s documentation confirms a detached object stops receiving any change made to the source, and the only way back is an undo taken immediately after.
An override keeps the link alive, so later component edits still reach that instance, minus whatever you changed by hand. Detaching removes the link for good. Some organizations track how often detaching happens through design system analytics, which is really a measure of how much people trust the library.
How to Edit a Component in Figma: Step by Step
Every route to the main component starts from an instance already sitting on the canvas. Most instances get dragged out of the assets panel, though it makes no difference how a given one arrived.
- Select an instance, either on canvas or in the layers panel.
- Right-click and pick Go to main component. Figma jumps to the source wherever it lives in the file.
- Edit the source object directly. Layers, text, fills, auto layout settings, all of it.
- Look back at the instances. They’ve already changed, including in any file subscribed to the same library.
Figma still has no native keyboard shortcut for jumping to a main component, so most designers stick with the right-click menu, the button in the properties panel, or something mapped manually at the OS level.
Miss the second step and your edit lands on the instance instead, quietly creating an override rather than a real component edit.
A main component doesn’t have to live on the same page as its instances, and in larger files it usually doesn’t. Most teams park every main component on a dedicated page, well away from the screens people work in every day.
How Layer Structure and Naming Affect What You Can Edit
Layer names are not decoration. They decide whether a property works at all.
Every component property binds to a specific layer. Rename that layer inside the main component and whatever pointed at it, a property or an instance swap target, stops resolving.
Consistent naming is what lets a boolean property find the same icon layer across every variant in a set. Nesting matters too, since the arrangement of frames and groups decides which layers can even be exposed as properties. Layer order is the one people forget about. It changes how overrides get presented to whoever ends up using the instance, not just how the thing looks on canvas.
Mismatched names between variants inside the same component set break properties constantly, and nothing in the UI warns you.
Naming conventions across a library matter more than new users expect, something covered in more depth in component best practices.
The component description field documents intended use for whoever inherits the file later, without touching a single layer.
Match layer names across every variant in a set, capitalization included, so the properties panel reads them as one property instead of several disconnected ones.
Editing Component Properties and Variants
Properties are the controls you expose on a main component so instances can change without breaking the link back to the source. Boolean, text, instance swap, variant. All four get created and edited on the main component, never on an instance.
Figma’s S-1 put monthly active users at 13 million, and two thirds of them are not professional designers (Figma S-1 filing, SEC, 2025). That second half of the number is the part worth thinking about when you design properties, because the people flipping your boolean toggles are often PMs and marketers who will never open the main component.
Buttons dominate everything else. 23.6% of all design system components are buttons, more than any other single type (Supernova, 2023), which is why they’re almost always the first thing a team wires up with boolean and instance swap properties, long before anything complicated.
There’s a measurable payoff. Designers working from a relevant design system complete tasks 34% faster than those working without one (Figma, 2025).
Boolean, Text, and Number Properties
Boolean properties toggle a layer’s visibility. That’s the entire scope of them in Figma right now.
Text properties expose a text layer’s content so it can change per instance, which is how a label goes from “Submit” to “Send” with nothing detached. Number properties expose a numeric value instead, usually padding or a stroke weight tied to a nested layer.
A button component with a boolean icon toggle and a text-controlled label covers most of what a design system actually ships day to day.
Instance Swap Properties
An instance swap property hands the person using the instance the ability to replace a nested component with a different one, nothing detached.
Say a button with a swap property on its icon slot. One team drops a checkmark in, another drops in an arrow, both working from the same source button.
Preferred values narrow that swap list down to a handful of approved options rather than every component in the library. Skip it and the swap menu turns into a free-for-all.
Variant Properties and Component Sets
Variants group related states into one component set instead of scattering them as separate, unrelated components. States are the obvious case: default, hover, pressed, disabled. Sizes work the same way, and so do style tiers like primary, secondary, ghost.
Combining components as variants merges what used to be a pile of individually named components into one switchable set, with each variant sharing the same property structure.
It’s worth doing once a component passes two or three states, which is roughly the point where separate unlinked components start multiplying fast. The variant panel replaced that whole mess.
Dev Mode surfaces every property covered here to developers inspecting the file later, without giving them edit access to the underlying layers.
How Auto Layout Behaves Inside a Component
Auto layout settings on a main component decide how every instance resizes when its content changes. Width and height each get a resizing mode, and every nested frame inside the component can carry its own.
- Fixed stays at a set size no matter what the content or the parent frame does
- Hug contents shrinks and grows to match whatever sits inside it
- Fill container stretches into whatever space the parent frame has available
Padding and gap values set on the main component’s auto layout frame carry through to every instance automatically.
Nested auto layout frames resize independently of their parent, and that’s where most sizing confusion starts.
Squarespace’s design platform team relied on exactly this behavior when they replaced an older shared library with a new one built on auto layout, tracking team adoption as the rollout progressed (Figma, Design System Analytics blog, 2019).
Figma added a second layout mode at Config in May 2025. Grid sits alongside the existing Horizontal and Vertical options and handles two-dimensional, CSS Grid-style layouts.
The most common way auto layout breaks inside a component is a fixed-width child sitting in a hug-sized parent. The parent has nothing consistent left to hug.
What Happens to Instance Overrides When You Edit a Component
Most overrides survive a component edit. Some don’t, and the difference comes down to whether the property they touched still exists afterward.
| Override type | Survives edit | Why |
|---|---|---|
| Text override, existing property | Yes | Property still resolves, override sits on top |
| Boolean override, existing property | Yes | Same layer, same property, untouched |
| Override on a deleted or renamed layer | No | Property no longer resolves to anything |
Resetting an override is a different thing from losing one. Resetting is deliberate, done from the instance’s properties panel, and it pulls the instance back to whatever the main component currently looks like.
A small marker in the layers panel flags any instance carrying overrides, so a quick scan tells you which ones have drifted from the source.
New properties added to the main component reach every instance automatically, arriving with default values that won’t conflict with overrides on properties that already existed.
Detached instances are outside all of this. Once detached, an object stops listening to the main component entirely, overrides or not.
When to Detach an Instance Instead of Editing the Component
Detaching isn’t a shortcut. Once a few more edits land on top of a detached frame, there’s no clean path back.
Detach when the variation will never repeat anywhere else in the file, when you need a layer structure the component’s properties simply can’t support, or when you’re testing a one-off idea that has no business becoming a component yet.
Go back to the main component instead if:
- the change should reach every instance, not one
- a property or variant already covers what you’re trying to do
- other designers are counting on that component staying linked to the library
Some teams detach, customize, then remove the original component entirely when they’ve decided to break away and rebuild from the customized version.
Publishing Edited Components to a Library
Inside the file where the main component lives, changes appear instantly. Anywhere else, nothing moves until you publish.
- Open the library publish panel from the toolbar
- Review which components, styles, or variables changed
- Hide anything not meant for other teams, base and primitive components especially
- Write a short note describing what changed, then publish
Subscribers see a badge on their Assets panel and choose whether to update one instance at a time or the whole file at once (Figma Help Center).
85% of design systems include component documentation as a standard part of the system (Sparkbox, 2022, survey of 219 practitioners). That note you write at publish time is a small piece of the same habit, not a formality to skip when you’re in a hurry.
The same survey found 84% of design system subscribers are required to use the system for their work, which is why an unpublished change leaves almost everyone downstream out of sync rather than inconveniencing one designer.
Component descriptions and documentation practices written at the source carry more weight than notes bolted on afterward, since they travel with the component into every file that uses it.
Getting this part right is what makes developer handoff predictable instead of a guessing game about which version is current.
Common Problems When Editing Components
Most component problems are self-inflicted. Figma is rarely the culprit.
| Problem | What happens | Fix |
|---|---|---|
| Editing an instance by mistake | Creates a silent override instead of a real component edit | Check for the purple diamond before editing |
| Renaming a layer casually | Breaks the property or instance swap target bound to it | Rename from inside the main component, check every variant |
| Editing a nested component | Changes ripple into every unrelated parent that uses it | Confirm which parents reference it first |
| Forgetting to publish | Teammates stay on an outdated version without knowing it | Publish and write a short note every time |
39% of design system subscribers say their system is documented poorly, and 35% say it’s unclear what’s old, broken, or coming soon (Sparkbox, 2022). Both numbers trace back to the habits in that table rather than to some separate documentation failure sitting off to the side.
A component set with mismatched variant names belongs in here too. It breaks naming consistency quietly, without throwing any visible error.
Following established naming and editing conventions catches most of this well before it reaches a shared library.
When Editing a Component Does Not Work
A handful of situations stop a component edit cold, and none of them are bugs.
- A detached instance never receives another update from the main component, by design
- A conflicting override blocks the new value from showing until someone resets it
- Unpublished library components only update inside the source file, nowhere the library is subscribed
- Viewer-only permissions block edit access entirely, no matter how the component is structured
Publishing a library requires a paid plan per Figma’s own documentation, so a file on the free tier can block that action outright regardless of skill or setup. Detaching an instance works on any plan, free included.
Checking a free versus paid plan is worth doing before assuming a missing option is a bug.
Dev Mode can look like an editing surface at first glance, since it lists every property right there in the inspector. It never doubles as one.
A look at the Dev Mode panel still helps confirm whether a stuck property is a permissions problem or something else, even without edit rights.
None of these conditions mean the component is broken. They mean the edit is happening in the wrong place, or by the wrong person.
FAQ on How To Edit A Component In Figma
Can You Edit a Component Without Affecting Its Instances?
No. Editing the main component propagates to every linked instance, by definition.
To change one instance only, override it directly, or detach it, which permanently removes any future sync back to the source.
Is There a Keyboard Shortcut to Jump to a Component’s Main Version?
Figma has no native shortcut for Go to main component. The community has been asking for years.
You’re stuck with the right-click menu or the properties panel button, unless you map a custom OS-level shortcut yourself.
Can You Edit More Than One Component at the Same Time?
Not for nested component properties. Selecting multiple instances at once strips those controls out of the properties panel, so each instance needs individual edits.
Figma’s separate bulk-edit tool can still update matching text or color across identically named layers in one pass.
Does Editing a Component in One File Affect Other Files Using the Same Library?
Only after you publish. A local edit stays inside the file where the main component lives until then.
Once published, every subscribed file gets an update badge and can apply the change to its own instances.
Can You Undo a Component Edit After Publishing?
Yes, through version history rather than a simple undo. Restoring an earlier version reverts the component to that state.
Instances still show a prompt to update to the newer published version, per Figma’s own support team.
Where Does Editing a Component in Figma Most Often Break Down?
Almost always at the instance level. A detached link, a lingering override, or a library component that was edited but never published will block a change that looks perfectly correct inside the main component.
Three checks resolve most of it, in the order each one tends to be the actual cause:
- Confirm the instance carries a purple diamond and isn’t a detached frame
- Look for an active override on the affected property
- Verify the library was published, not just edited
Checking detachment and overrides first costs you one extra step on the rare file where a stale library was the real problem. Fair trade for how much faster it is everywhere else.
Once edits behave predictably across a file, the next step is building a design system in Figma, where these components turn into a product’s shared foundation.
