Framer components are reusable design units with variants and properties, similar to Figma components but rendered as live HTML in the browser. They are the foundation of any production Framer site: build a button once with three variants and four properties, and every instance across the site updates when the master changes. This guide covers how components actually work, the patterns that scale, and the mistakes that ruin design systems.
What Framer Components Actually Are
A Framer component is a saved layer or layer group that can be instanced anywhere in the project. The original is the master. The copies are instances. Edit the master, every instance updates. Detach an instance, it becomes a standalone layer that no longer reflects master changes.
Components support two power features that flat reusable layers do not. Variants let one component have multiple states, like Default, Hover, Active, and Disabled for a button. Properties let an instance receive editable inputs from the canvas, like a button label, an icon, or a color override.
Together, variants and properties make Framer components behave like a real design system. A single Card component can render a blog card, a feature card, a pricing card, and a testimonial card by switching variants and changing property values. The site stays consistent because every card pulls from the same master.
Components live in the Assets panel on the left side of the canvas. Drag from the panel to add an instance. Right-click an instance and select Detach to break the link.
Creating Your First Component
Select a layer or layer group on the canvas. Press Command-K, or right-click and choose Create Component. Framer wraps the layer in a component master and creates an instance in place. The original moves to the Assets panel.
Best practice is to name the component immediately. Naming convention matters as your library grows. Our team uses Category/Variant naming, like Button/Primary, Card/Pricing, Hero/Centered. The slash creates folders in the Assets panel, which keeps the library navigable past 50 components.
Once the master exists, double-click into it from the Assets panel to edit. Changes propagate to every instance. The canvas shows a yellow outline on the master so you remember where you are. Exit by clicking outside or pressing Escape.
Avoid creating components for one-off layouts. Each component adds cognitive overhead. The right time to convert a layer to a component is when you need a second instance, or when you know the design will repeat across pages.
Variants: Multiple States in One Component
Variants are how a single component handles multiple states. Click the master in the Assets panel, then in the right panel click Add Variant. The new variant appears below the original. Edit it independently. The component now has two states.
Common variant patterns are: states like Default, Hover, Active, Disabled for interactive elements. Sizes like Small, Medium, Large, XL for buttons or cards. Themes like Light and Dark for components that need to render against different backgrounds. Layouts like Vertical and Horizontal for cards and feature blocks.
Variants connect via interaction transitions. Set the Default variant to transition to Hover on mouse enter, and Active to fire on press. Framer animates between variants automatically using the transition curve set on the master. This produces the smooth, fluid micro-interactions that Framer is known for.
The trap to avoid is variant explosion. A button with five sizes, four colors, three states, and two icon positions has 120 variants. That is unmaintainable. Use properties for orthogonal options like color and icon, and reserve variants for states and structural changes.
Properties: Making Components Editable
Properties are component inputs that appear in the right panel when an instance is selected. They let editors customize an instance without modifying the master. Click the master, scroll the right panel to Properties, and click Add Property.
Framer supports several property types: text for editable strings like button labels and headings, number for counts and dimensions, boolean for toggles like show icon yes or no, color for fills and strokes, image for visual swaps, link for URLs on buttons and cards, and enum for picking from a defined list.
Connect a property to a layer by selecting the layer inside the master, opening the relevant control, and choosing Connect to Property. The control switches from a literal value to a reference to the property. Now every instance can override that value individually.
This is the killer feature of Framer components. A Pricing Card master with Title, Price, Feature List, and Highlighted properties produces three different pricing tiers from one component, each instance pulling its own data from properties. The CMS extends this further by binding properties to CMS fields, which we covered in our Framer CMS guide.
Code Components vs Visual Components
Framer supports two component models in the same project. Visual components live entirely on the canvas. Code components are React components written in TypeScript and rendered inside Framer.
Use visual components for everything that can be expressed as layers and styles. Buttons, cards, heroes, sections, navigation, footers. The visual model is faster to build and easier for non-developers to edit.
Use code components for: interactive elements that need state, like a tabbed switcher or an accordion. Data-driven UI like charts or tables that pull from APIs. Third-party widget integrations that need custom styling. Calculators, configurators, and product demos with custom logic.
Code components also support property controls, similar to visual components, so editors can adjust them without touching code. We walked through the build process in our Framer beginner tutorial.
Building a Reusable Design System
A design system in Framer is a Library file containing the team’s components, color tokens, font tokens, and shared patterns. Other Framer projects can import the Library, getting access to every component without copying or rebuilding.
Set up a Library by creating a new Framer project, building the components, and publishing as a Library from the share menu. Other projects add the Library through Workspace Libraries. Updates to the source Library propagate to consuming projects on next refresh.
The components your design system needs depends on your scope. A minimal kit includes: a button with primary, secondary, and ghost variants, a card with content and image variants, a section wrapper with consistent padding, a navigation header, a footer, a hero block, and a CTA block.
Add components incrementally as patterns emerge. Premature abstraction creates components that fit no real use case. Build components in real projects first, identify the patterns that repeat, then promote them to the shared Library.
Common Component Mistakes
Three mistakes derail Framer component libraries. Watch for them.
First, building components without auto-layout. Components built with absolute positioning break the moment content length changes. Always use horizontal or vertical auto-layout with proper padding and gap. Set hug or fill behaviors deliberately so the component responds to content.
Second, mixing concerns in one component. A pricing card that includes the section heading, three pricing tiers, and the CTA below is too coarse. Split it into a Section component, a Card component, and a Button component. Composition gives editors flexibility and keeps the masters simple.
Third, not naming variants and properties clearly. Variant 1 and Variant 2 are useless six months later. Name variants by their state, like Default, Hover, Active. Name properties by their role, like Label, Icon, Highlighted. Future you will thank present you.
When Components Cost More Than They Save
Components are not free. Each component adds maintenance overhead. Editors need to learn the component vocabulary. Updates to a master can ripple unintended changes to instances elsewhere.
Skip components for: layouts that appear once on the entire site, marketing pages that need very specific custom treatment, prototypes that will be discarded after testing, and small projects under five pages where the maintenance cost outweighs the reuse benefit.
For everything else, components are essential. The Framer sites we ship for production typically have 30 to 80 components covering buttons, cards, sections, navigation, and content blocks. The component library is what lets a designer or content editor maintain the site after launch without re-engaging the build team.
Frequently Asked Questions
What is the difference between Framer components and Figma components?
Framer components render as live HTML in the browser, with variants triggered by real interactions. Figma components are static design artifacts. Framer components support code, data binding, and CMS connections. Figma components do not.
Can I use Figma components in Framer?
You can import Figma files into Framer, which converts layers to Framer components. The conversion is not perfect for complex variants and auto-layout edge cases. Plan for cleanup after import. For new projects, building components natively in Framer is cleaner.
How many variants should one component have?
Three to six is the sweet spot for most components. Above that, the component is doing too much. Use properties for orthogonal options like color or icon, and reserve variants for states and structural changes.
Can I share components across multiple Framer projects?
Yes, through Workspace Libraries. Build a library project, publish it as a library, and add it to other projects in the workspace. Updates to the source library propagate to consuming projects automatically.
Do Framer components work on mobile and tablet?
Yes. Components support breakpoints. Define how each variant looks on desktop, tablet, and mobile. Auto-layout settings carry across breakpoints, so well-built components remain responsive without rework.
Want a Framer site with a clean component library that your team can maintain after launch? See Framer Websites pricing and book a kickoff this week.