Framer Components and Variants: A Complete Guide

Framer components are reusable design elements you build once and place anywhere, and variants are the different states of a single component, like a button’s default, hover, and pressed looks. Together they let you design a consistent site quickly: change the master component and every instance updates, while variants handle interaction and responsive states without duplicating work.

Key takeaways

• A Framer component is a reusable element you define once and reuse across pages and projects.
• Variants are the alternate states of one component, such as default, hover, active, or empty.
• Editing a master component updates every instance, which keeps a site consistent and fast to maintain.
• Variants combined with interactions create animated, stateful elements with no custom code.
• Use properties to expose text, color, and visibility so one component covers many use cases.
• Plan your component library early to avoid duplicate elements and inconsistent styling later.

What components are and why they matter

A component in Framer is a self-contained design element you turn into a reusable building block. A button, a card, a navigation bar, a testimonial, or a pricing tile can all become components. Once you create one, you place copies, called instances, throughout your site. The key benefit is single-source editing: when you change the master, every instance reflects the change instantly.

This matters most as a site grows. On a small page, copying elements by hand feels fine. On a site with dozens of pages, manual copies drift apart, and a brand update becomes hours of tedious editing. Components prevent that drift. They make your design system real rather than a document, because the rules live inside the elements themselves.

Understanding variants

A variant is a distinct state of a single component. A button might have a default variant, a hover variant with a slightly brighter color, and a pressed variant that looks tapped. A card might have a loading variant, a filled variant, and an empty variant. All of these belong to one component, and Framer lets you switch between them based on interaction or logic.

Variants are powerful because they keep related states together. Instead of three separate button designs scattered across your file, you have one button with three variants. When you update the base style, all variants inherit the change where it makes sense, and you only adjust what truly differs between states.

Common variant patterns

A few variant patterns show up in almost every project:

• Interaction states: default, hover, and pressed for buttons and links.
• Content states: empty, loading, and filled for cards, lists, and forms.
• Selection states: selected and unselected for tabs, toggles, and menu items.
• Responsive states: desktop and mobile versions of the same component.

Defining these states up front means your interactive elements behave predictably everywhere they appear.

How components and variants work together

The real power shows up when you connect variants to interactions. In Framer, you can tell a component to move from its default variant to its hover variant when the cursor enters, then back when it leaves. You can add a transition so the change animates smoothly. The result is a button or card that feels alive, built entirely with variants and no hand-written code.

Because the animation lives inside the component, every instance behaves the same way. You design the hover effect once on the master, and every button on every page hovers identically. This consistency is hard to achieve when you animate elements individually, and it is one of the strongest reasons to build with components from the start.

Step by step: build a component with variants

Here is a clear sequence for creating a reusable button with interaction states.

1. Design the base element. Build your button on the canvas with the text, padding, color, and corner radius you want for the default state.
2. Create the component. Convert the element into a component so it becomes reusable.
3. Add a hover variant. Duplicate the default variant, rename it hover, and adjust the color or scale to show the hover effect.
4. Add a pressed variant. Create one more variant for the pressed state with a subtle change that signals a tap.
5. Wire the interactions. Set the component to switch to the hover variant on cursor enter and the pressed variant on tap, with smooth transitions.
6. Expose properties. Add a text property so each instance can show different label text without breaking the component.
7. Place and reuse. Drop instances across your pages, knowing every one shares the same behavior.

With that done, a single edit to the master button updates color, spacing, or animation everywhere it appears.

Properties make one component do more

Properties are the controls you expose on a component so each instance can differ without becoming a new component. The most common is a text property that lets every button instance carry its own label. You can also expose image properties for cards, color properties for accents, link properties for destinations, and visibility toggles to show or hide an icon. Each property you add widens the range of situations a single component can handle, which is exactly what keeps your file lean as the site grows.

This is where components scale. A single card component with text, image, and link properties can render an entire blog grid, a testimonial wall, or a feature list. You are not building many cards. You are building one flexible card and feeding it different content. That keeps your file small, your styling consistent, and your edits fast.

Components versus code components

Most components you build are visual, created on the canvas with variants and properties. Framer also supports code components, which are written in React for logic or data that visual components cannot express, such as pulling live data or rendering a custom chart. For the vast majority of marketing sites, visual components and variants cover everything you need. Reach for code components only when a design genuinely requires custom logic. Our guide to Framer code components covers when and how to take that step.

The decision is about fit. Visual components keep work in the design tool and accessible to your whole team. Code components add capability but require React knowledge and testing. Start visual, and add code only when the visual approach hits a real wall.

Common mistakes to avoid

A few habits cause trouble as projects grow:

• Duplicating instead of componentizing. Copying an element ten times creates ten things to update. Make it a component the moment you reuse it.
• Too many variants. If a component has a dozen variants, it may be doing too much. Split it into smaller, focused components.
• Hard-coded content. Baking text or images into the master forces a new component for each use. Expose properties instead.
• Skipping naming. Clear names for components and variants keep a growing library navigable for you and your team.

Real-world examples of components in action

Seeing how components apply to common page elements makes the concept concrete. A few examples cover most of what a marketing site needs.

Consider a navigation bar. Built as a component, it lives in one place, and a change to a link or the logo updates the nav on every page at once. Add a mobile variant, and the same component switches to a compact layout on smaller screens. You design the navigation once and trust it everywhere.

Take a pricing card. Build one card component with text properties for the plan name, price, and feature list, plus a variant for the highlighted plan. Drop three instances on the page, feed each different content, and switch one to the highlighted variant. You now have a full pricing section from a single reusable card, and adjusting the card’s padding or shadow updates all three together.

Or look at a testimonial. A testimonial component with image, quote, and name properties can render an entire wall of social proof. Each instance shows a different customer, but they share identical styling. If you decide the quotes need larger text, you change the master once and every testimonial follows. This is the pattern that makes large sites manageable rather than overwhelming.

Organizing variants so they stay clear

As components gain variants, organization keeps them usable. Name each variant for the state it represents, such as default, hover, or empty, rather than leaving generic labels. Clear names let you and your team understand a component at a glance and wire interactions to the right state without guessing.

Group related variants logically. A button’s interaction states belong together, while content states like loading and filled form their own cluster. When a component starts to feel crowded with unrelated variants, that is a signal to split it into focused components instead. A button that also tries to be a card is harder to maintain than two clear components. Keeping each component tight and well named is what lets a library scale without becoming a maze.

Building a maintainable component library

The teams that move fastest in Framer treat their components as a library, not a pile. They name elements clearly, group related components, and decide early which patterns become reusable. A button, a card, a section header, and a navigation bar are obvious candidates. Building these first gives you a kit that makes every later page faster to assemble.

For a deeper look at structuring reusable elements, our complete Framer components guide walks through library organization, and our Framer variants guide goes further into building rich interactive states. Read both as you plan a larger site, because a strong component foundation pays off on every page you build afterward.

Frequently Asked Questions

What is the difference between a component and a variant in Framer

A component is a reusable design element you build once and place anywhere. A variant is one of the alternate states of that component, such as a button’s default, hover, and pressed looks. One component can hold many variants.

Do components update everywhere when I edit them

Yes. When you edit the master component, every instance across your pages updates to match. This single-source editing is the main reason components keep a Framer site consistent and quick to maintain.

Can I animate between variants without code

Yes. Framer lets you switch a component from one variant to another on interactions like hover or tap, with smooth transitions. This creates animated, stateful elements entirely within the design tool, no code required.

When should I use a code component instead

Use a code component only when a design needs custom logic that visual components cannot express, such as pulling live data or rendering a custom chart. For most marketing sites, visual components and variants cover everything you need.