Framer components, code overrides and plugins — what to use when

Framer gives you three ways to add custom behaviour to a project: code components, code overrides and plugins. They look similar enough from the outside that people reach for the wrong one constantly, and the result is almost always the same — a job that should have taken ten minutes turns into an afternoon of fighting the tool.

The distinction is simpler than the documentation makes it feel. It comes down to one question: what are you actually trying to change?

Code components: adding a new thing to the page

A code component is a React component you place on the canvas like any other layer. It has its own position and size, it appears in the layer list, and it exposes its own settings in the properties panel.

Reach for one when you need something Framer cannot draw: a WebGL background, a canvas effect, a live clock, a QR code, an interactive map of your own. The test is whether you are adding a new element. If a designer would draw a box for it in a wireframe, it is a component.

Property controls are the real product

The code is the easy part. What makes a component usable six months later — by you or by a client — is the controls you expose. Every value someone might reasonably want to change should be a control, and every control should be named for what it does rather than what the variable is called.

A component with three well-chosen controls gets reused. The same component with a hard-coded colour gets duplicated and edited, and then you have four versions to maintain.

What a component cannot do

A component is self-contained by design. It cannot restyle your navbar, hide a button elsewhere on the page, or reach into sections it does not own — and it should not try. Components that mutate the rest of the document are fragile the moment someone places two of them on one page, and they will not pass Marketplace review.

If your instinct is to have a component reach outward, you almost certainly want one of the other two tools.

Code overrides: changing something you already designed

An override is a function that wraps a layer you built in Framer. The layer keeps everything about itself — its design, its links, its CMS bindings, its position in the layout. The override only changes how it behaves.

This is the right tool when the element already exists and already looks correct, and you need new behaviour on top: hide it from signed-out visitors, copy something to the clipboard when it is clicked, redirect based on stored state, or drive an animation Framer's own controls cannot express.

The underrated reason to prefer overrides

Overrides preserve bindings. If a button's label and destination come from a CMS collection, rebuilding it as a component means recreating every one of those bindings by hand — and quietly losing any you forget. An override leaves the layer exactly where it is and touches nothing else.

On any project with CMS-driven buttons, cards or navigation, that alone decides it.

Hiding things is less trivial than it looks

The most common override is one that conditionally hides a layer, and it has a trap. Returning nothing from an override does not necessarily remove the space the element occupied — the wrapper around it can survive as a zero-width item in a flex layout, so a stack with a gap now shows a doubled gap where your element used to be.

If you hide things conditionally, check the spacing in both states rather than assuming an invisible element takes no room.

Overrides are invisible, so name them

Nothing on the canvas indicates that a layer carries an override. Six months later nobody remembers which ones do. Name them for their effect rather than their mechanism, keep them few, and keep them in one file per concern.

Plugins: changing the project, not the site

This is the option people forget exists, and it is the one that solves the most painful problems.

A plugin runs inside the Framer editor. It never ships to visitors. It reads and writes your project itself: pages, layers, styles, CMS collections and items. Nothing it does appears in your published bundle, because it is a tool for the person building the site, not for the person visiting it.

When a plugin is obviously right

Any work that is repetitive and structural. Renaming a hundred layers to a convention. Generating a social image for every CMS entry. Finding every oversized image in a project and replacing it. Auditing a site for missing alt text. Bulk-editing a collection field across two hundred items.

The signal is simple: if you catch yourself performing the same click sequence for the twentieth time, you are looking at a plugin, not a component.

The mistake this prevents

The worst architecture in Framer projects is a component that tries to do editor work at runtime — scanning the live page, rewriting other sections, patching things that should have been fixed in the project. It runs on every visit, for every visitor, to do a job that should have happened once at design time. It is slow, it is unpredictable, and it breaks when the page changes.

Doing it once in a plugin is faster to build, faster to run, and permanent.

The decision rule

Ask what you are changing.

Adding a new element to the page? That is a component. Changing how an element you already designed behaves? That is an override. Changing the project itself, in the editor, usually in bulk? That is a plugin.

Three questions, and they resolve almost every case.

Where people go wrong

Rebuilding a designed section as a component

A section already exists in Framer, looks right, and is bound to the CMS — and someone rebuilds it in code to add one behaviour. Now the design lives in a file instead of on the canvas, the client cannot edit it, and the bindings are gone. An override would have added the behaviour and changed nothing else.

Using a component for one-off work

If the job is to fix something across the project once, a component is the wrong shape entirely. It ships forever to solve a problem that existed for an afternoon.

Reaching for code before checking the toolbox

Framer covers a lot natively — variants, breakpoints, effects, CMS filtering and sorting. The cheapest custom code is the code you did not write, and native features keep working when Framer updates. Check first.

They work together

These are not competing choices so much as different layers of the same stack. A realistic project uses a plugin to prepare the content, components for the elements Framer cannot draw, and a handful of overrides to wire behaviour onto the design you already built.

Get the split right and each piece stays small. Get it wrong and one of them grows to do all three jobs badly.