Framer to React

The short answer

There's no button in Framer that exports a site as React. Framer is built on React, which is why people expect one, but a published site runs on Framer's runtime and hosting. Third-party tools fill the gap, and they come in two kinds that do different jobs:

• Component exporters (React Export with the unframer CLI, Reframe) copy components you pick into a React app you already have. Good for reusing a Framer-designed section inside an existing codebase; they don't export a site.
• Whole-site converters (FNJ, ConvertFramer, and the Full Site Export plugin's readable mode) turn a published site into a React project.

Among the whole-site options, what matters is whether the result is still your site. FNJ gives one file per section, named as you named it in Framer, composed by a view and rendered by a route, and it still renders the original page exactly, animations and breakpoints included: a project a developer can open and continue.

Framer to React tools, compared

Read off each tool's own page on 20 October 2026; prices and features change, so check before you buy. Full Site Export also has exact static and Next.js copies of a site; its readable React mode is the one listed here. ConvertFramer's automated tier doesn't keep Framer's responsive behaviour, and puts animations in its paid migration service.

What you actually get

A Next.js App Router project. The parts that matter:

src/sections/home/Hero.tsx        one file per Framer section
src/sections/home/Pricing.tsx     named from your Framer section names
src/sections/shared/Footer.tsx    sections reused across pages, emitted once
src/views/HomePage.tsx            composes that page's sections
src/styles/custom.css             your CSS, last in the cascade
app/route.ts                      serves the page, prerendered at build
app/work/project/route.ts         nested routes preserved as authored

Section names come straight from Framer, so the file tree reads like your layer panel. That is the whole trick: the names you already chose become the API of the codebase, instead of a developer having to invent them after the fact from a wall of generated markup.

Text lives apart from markup

Each section's copy is hoisted into a named copy export, so changing a headline is editing a string, not editing JSX:

import { copy } from "@/src/sections/home/Hero/copy";

This is also what makes the MCP tools safe on a converted site — an agent rewriting a headline changes one string and cannot disturb the layout around it.

One caveat: Framer's runtime, which still loads from Framer's CDN, re-renders the text it controls after the page loads. Editing a string changes the HTML search engines read, but visitors can still see Framer's original until you change it in Framer and convert again. Styles you write in the exported CSS always apply.

What this is not

Worth being blunt, because the category oversells here. The components are your original markup and inline styles organised into files— not a hand-written rewrite. Class names are Framer's generated ones. Framer's runtime still runs the page, loaded from Framer's CDN, which is what keeps every animation identical and also what keeps this mode off the top of the Lighthouse chart.

The honest framing: this is a conversion optimised for ownership and fidelity. The HTML modemakes the same trade as plain static files instead of components; neither mode removes Framer's runtime. No converter turns a Framer design into code that looks hand-authored, and any that claims to is describing a rewrite you would still have to check line by line.

Related: All routes from Framer to code · How to export a Framer site · Convert Framer to Next.js · Framer to HTML converter · Framer vs owning your code

Starting a new site instead?

FAQ