How converter works
The converter rebuilds your code as native Webflow elements wherever it can and falls back to embedded custom code where it can't.
Wherever possible, your code is recreated as native Webflow elements: layout,
content, styling and the CSS states Webflow itself supports as class variants
(hover, transitions, keyframe animations) all come across as editable elements and
Style panel properties. :focus, :active and
:visited rules have no Webflow variant to map onto, so they aren't
recreated as Style panel states. Features that don't have a native Webflow equivalent are preserved
as custom code instead, so nothing gets silently dropped. The goal is to keep as
much of your page editable as possible while making sure advanced functionality
still works after publishing.
Custom code
Some browser features simply can't be represented as native Webflow elements: libraries like GSAP and ScrollTrigger, scroll-based interactions, click handlers, Intersection Observers and unsupported CSS selectors or pseudo-elements all fall into this bucket. Rather than dropping them, the converter inserts them as Embed elements within the converted page. Embedded code keeps working on Preview and on your published site, but, unlike native elements, it isn't editable inside Designer. If you'd rather manage it centrally, you can move the generated code into your project's Page Settings or Site Settings and remove the Embed element afterward.
The converter does not generate Webflow's native interactions. Nothing is written to IX2 or IX3 and no timelines, triggers, or animation steps appear in the Interactions panel after pasting. Your JavaScript is folded into a script embed and runs from there instead. The behaviour is preserved, but it lives in code rather than as a Webflow interaction you can edit visually. Rebuilding an animation in the Interactions panel is a manual step and native-interaction output is something we plan to support later.
Designer view vs. the published site
A converted page can look different inside Designer than it does once published and
that's expected. Designer doesn't execute JavaScript inside Embed elements, so a
page that relies on JavaScript for animation or reveal effects shows its static
layout while you're editing. To see the real result, turn on
Render custom code in Preview, or publish to your
.webflow.io staging domain. Either way, the embedded scripts run
normally and the page behaves as intended.
CSS vs. JavaScript animation
CSS animations and transitions convert into native Webflow styles, stay editable through the Style panel and render correctly inside Designer. Animations driven by GSAP, ScrollTrigger, or custom JavaScript are preserved as custom code instead. They run correctly once previewed or published, but they aren't editable through Webflow's Interactions panel and won't animate while you're editing. Both approaches are fully supported during conversion; which one to use just depends on what your project needs.
CMS Collections
CMS Collection Lists aren't converted directly into native Webflow Collection List elements. Instead, the converter detects CMS-style layouts and recreates them as Div blocks that follow the same wrapper and item structure a real Collection List would use, which keeps the layout intact and makes it straightforward to reconnect the section to your CMS after pasting.
To reconnect it: add a Collection List from the Add panel, replace the generated wrapper with the Collection List structure, move the converted elements into the Collection Item and connect them to your CMS fields. If you've used Relume components before, this will feel familiar: the generated structure is a placeholder you swap for a native Collection List while keeping the original design.
CSS variables
On (default): the converter replaces every CSS variable with its computed value before generating Webflow elements. Use this when you're importing AI-generated code, converting a site from another platform, or working in a new Webflow project that doesn't yet contain the matching variable collections. Since the destination project has no original variables to bind to, replacing them with literal values keeps the pasted styles rendering correctly.
Off: the converter preserves variable references wherever possible. Use this when you're importing content back into the project it came from (or another project that already has the required variable collections), so the pasted styles stay linked and continue to update when you change those variables later. Before importing into an existing project, make sure the converted class names don't already exist there; duplicate names make Webflow create new class variants, which can leave your class naming inconsistent and prevent variables from mapping the way you'd expect.