If you're a developer inheriting a Framer site — handed off by a designer, or picking up a marketing site you now need to maintain in code — here's what to actually expect from a Framer-to-Next.js conversion, without the sales framing.
What a real conversion produces
A proper Next.js export gives you an actual App Router project: package.json, next.config.js, tsconfig.json, and one route per page — either as genuine JSX Server Components with the markup split into reusable pieces, or (depending on the export mode) as route handlers serving Framer's original rendered output directly. Either way, it's a real, buildable, deployable Next.js project you can npm install && npm run build — not a wrapper or an iframe.
Where the two approaches actually differ
JSX-component output gives you real, editable React markup — you can open a component file and see actual JSX, refactor it, extend it, add real React state and logic on top. The tradeoff: reproducing Framer's runtime-driven interactions (hover states, click-triggered menus, scroll-linked transforms) in plain code is a genuine engineering problem, not a solved one — some interactions end up approximated or missing, because the data those interactions depend on simply isn't present in Framer's static output.
Runtime-intact output keeps Framer's actual JS running, wrapped in a Next.js route. Every interaction behaves identically because it's genuinely the same code — but you're not actually looking at editable component structure; you're serving the original HTML/JS payload through a Next.js shell. Good for "get this off Framer's hosting with zero behavior risk," less good if your actual goal is "give me code I can extend."
What to check before you commit to either
- Open a few component files (if JSX output) and judge the actual code quality — is it something you'd want to build on, or effectively obfuscated markup?
- Test every interactive element manually — menus, hover states, forms, any custom animation — don't assume "it converted" means "it all works."
- Check whether Framer's original class names were preserved or renamed. Renaming introduces real regression risk for a marginal readability gain; a good export leaves them alone.
- If you plan to keep developing the site in code going forward (not re-exporting from Framer again), JSX output is the only path that makes that realistic. If you're just trying to get off Framer's hosting bill with the least risk, runtime-intact is often the more honest choice.
Neither approach is strictly better — they answer different questions, and knowing which one you're actually asking is the first step.