Framer-to-HTML exports that strip Framer's runtime lose hover effects, and it's not a bug in the exporter — it's a structural property of how Framer builds them in the first place.
The short answer
Framer doesn't implement hover states with CSS :hover rules the way a hand-coded site would. Instead, its runtime attaches JavaScript event listeners to elements and computes style changes on the fly — reading the "before" computed style, the "after" state defined in the component variant, and animating between them with a spring or tween. None of that logic lives in the page's static HTML or CSS. It only exists inside Framer's minified JS bundle, which a runtime-stripping static export removes, along with Framer's CDN dependency, analytics, and hundreds of KB of runtime weight. (FNJ's HTML export keeps that bundle, loading it from Framer's CDN, so hover effects work as authored.)
So when a converter promises "pixel-perfect HTML export," and the hover states go dead, that's the tradeoff surfacing: no runtime, no runtime-computed behavior.
What we found digging into how it actually works
We went looking for exactly how much of this is really recoverable. Inspecting a real Framer site's DOM under an active hover, the pattern is consistent: Framer stacks a "Main" text/icon layer and a "Hover" layer in the same component, and on hover it animates a transform (commonly a translateY) to swap which one is visually in view — sometimes with a spring, sometimes a tween, always driven by JS, never by a CSS transition. We checked systematically: across a real site's hover interactions, zero of them had an actual CSS transition-duration captured — confirming this is JS/spring-driven, not CSS-driven, effectively everywhere.
What actually works
Two honest options, depending on what "export" means to you:
- Keep Framer's runtime intact. If the export wraps and serves the original page (assets on Framer's CDN, JS bundle untouched), every hover effect works exactly as authored — because it's genuinely the same code running. The tradeoff is you're not fully independent of Framer's CDN.
- Reconstruct hover behavior from captured runtime data. A tool that actually drives the live site in a real browser, hovers every interactive element, and records the exact computed style delta (not just the static HTML) can rebuild real CSS
:hoverrules with the true before/after values — closer to the original than guessing, but still an approximation of spring physics with CSS easing.
What doesn't work: parsing the static HTML/CSS alone. There's nothing there to recover — the data legitimately doesn't exist outside the runtime.
Quick check for your own site
Open dev tools, hover a link that visually changes, and watch the Styles panel. If you see a transition property with a nonzero duration, it might survive a stripped export. If you see the transform jump instantly to a new matrix value with no transition line, it's runtime-driven and will need one of the two approaches above.
Starting a new site instead? FNJ's AI website builder designs one from a description and a site you like, then gives you the code to host anywhere.
