Every Framer-to-code conversion tool that offers more than one output mode is really offering a choice between two different things you can optimize for — and you can't have both at their maximum at the same time. Here's the honest tradeoff.
Pure Next.js: keep everything exactly as it was
This mode keeps Framer's actual runtime intact — its animation engine, hover states, breakpoint variants, appear effects — so the converted site renders and behaves identically to the original. You get a real, deployable Next.js project: genuine .tsx source, a real package.json, something a developer can open, read, and extend.
What it's actually good at: pixel-perfect fidelity, code ownership, and getting off Framer's hosting and subscription entirely while keeping a site exactly as designed. What it's not: a guaranteed performance upgrade — since the runtime carries over, a heavy site stays heavy. We measured this directly across 10 real templates; see our full test results.
Hybrid HTML: rebuild for maximum Lighthouse score
This mode strips Framer's JS runtime, re-encodes and self-hosts every image as WebP, inlines fonts, and rebuilds animations using lighter CSS-based equivalents where possible. The output is static HTML with a fraction of the original JavaScript weight.
What it's actually good at: large, real, repeatable performance gains — we've measured single-page mobile Performance jumping from the mid-30s to the low-to-mid 80s on genuinely JS-heavy sites. What it costs: some of Framer's most JS-dependent interactive effects don't translate 1:1 into the lighter rebuild, so an extremely animation-heavy site may show small visual differences.
The actual decision
Ask which failure mode you'd rather have. If a client or stakeholder would notice a subtle animation difference before they'd notice a slow load time, use Pure Next.js. If the site's whole pitch is "look how fast this loads" — an agency portfolio, a Core Web Vitals-sensitive landing page — use Hybrid.
A reasonable middle path: convert with Hybrid first, since it's non-destructive to try, compare both against the original with real Lighthouse numbers, and only fall back to Pure Next.js for pages where the animation difference is genuinely a problem.