Every conversion tool has boundaries. Knowing them up front turns a frustrating surprise into a five-minute planned task.
Scripts and interactivity
All script tags are removed. This is a safety decision — importing arbitrary JavaScript into your site through a paste operation would be dangerous, and it would not work reliably inside the editor anyway. Anything driven by custom JS (sliders, tabs, counters, accordions) arrives as static markup.
What to do: rebuild the interaction with the matching Elementor widget. Tabs, accordions, carousels, counters and progress bars all exist natively and are more maintainable than imported scripts.
Forms
A form’s submit action and method are stripped, and the visible fields are preserved. A form that posts somewhere is an integration, not markup — carrying the endpoint across would silently send your visitors’ data to someone else’s server.
What to do: map it to an Elementor Form widget and configure the actions (email, webhook, integrations) on your own site.
Navigation menus
A nav can produce a Nav Menu widget, but the widget must be pointed at a real WordPress menu. There is no way to infer your site’s menu structure from someone else’s markup.
Pseudo-elements
The ::before and ::after pseudo-elements are not DOM nodes. Decorative shapes, quote marks, gradient overlays and underline accents drawn this way simply do not exist as elements and cannot become widgets. If a design detail is missing after conversion, a pseudo-element is the first thing to suspect.
Animations, transitions and sticky behaviour
Keyframe animations, scroll effects, transitions and sticky positioning are not carried over. Elementor has its own Motion Effects and sticky controls, which are better integrated with the editor anyway.
Third-party embeds
Only YouTube and Vimeo iframes are kept — everything else is removed rather than importing an unknown frame. Object and embed tags are removed as well.
Hover and focus states
Only the resting state of an element can be read. Hover colours, focus rings and active states need to be re-applied in Elementor.
Base64 images and local paths
Data-URL images and relative file paths cannot become Media Library attachments, so they are turned into empty image slots — with the original alt text kept as a caption so you know which picture belongs where.
CSS custom properties arrive flattened
If your source uses design tokens — --brand-500, --space-4 and so on — the variables themselves do not survive. The converter reads computed styles, and by the time a style is computed the browser has already resolved every var() reference down to a literal value. A button whose background is var(--brand-500) converts as the colour that variable happened to hold, not as a reference to it.
Nothing looks wrong afterwards, which is exactly why this one catches people out: the page renders correctly, but the property that made your design system maintainable is gone. Change the brand colour later and you are editing thirty widgets by hand.
What to do: rebuild the token layer on the Elementor side. Define your palette in Global Colors and your type scale in Global Fonts before you paste, then reassign the imported widgets to those globals. You only do it once, and you get the single-source-of-truth behaviour back. The converter has a Site colours and Site fonts mode precisely for this — it leaves colour and typography off the imported widgets so they inherit your Elementor globals instead of arriving hard-coded.
Named grid areas
Grid layouts convert through column and gap settings: grid-template-columns maps to an Elementor Grid container, and fractional units are preserved. What does not map is grid-template-areas — the named-region syntax where you draw the layout as a little ASCII picture and assign each child a name.
Elementor’s Grid container has no equivalent to named areas, so a layout built that way loses its placement and the children fall back to normal source order. The result is not broken, but it is not your layout either.
What to do: if you control the source, express the layout with grid-template-columns plus explicit spans rather than named areas. If you do not, expect to re-place the children once inside Elementor.
Fixed positioning is deliberately downgraded
Anything with position: fixed is rewritten to position: absolute during conversion, and the safety report tells you it happened. This is one of the few places where the tool intentionally changes your design rather than reproducing it.
The reason is containment. A fixed element is positioned against the browser viewport, not against its parent — so a fixed header, a sticky cookie bar or a floating chat bubble imported from someone else’s page would escape the section you pasted it into and float over your entire site, on every page that uses the template. Downgrading to absolute keeps it inside the imported block where you can see it and decide what to do.
What to do: if you genuinely want the element fixed, set it up with Elementor’s own sticky controls after import. They are aware of the editor, the admin bar and your header, which a raw CSS rule is not.
Web fonts: the name travels, the files do not
Typography converts as values — family name, size, weight, line height, letter spacing — and those land in Elementor’s typography controls. The font files are a different matter. A @font-face rule points at woff2 files hosted on the source site; nothing copies those to your server, and nothing registers the family with WordPress.
So a heading converted from a page using a self-hosted font will carry the correct family name and fall back to whatever your site actually has. It usually looks close enough that you do not notice until you compare side by side.
What to do: install the font on your own site first — through Elementor’s Custom Fonts, a Google Fonts selection, or your theme — and only then convert. If the family is already available, the imported typography lines up immediately.
How to tell which limit you hit
You do not have to guess. Two things in the result view answer it directly:
- The safety report lists what was removed or rewritten — stripped scripts, cleaned form actions, discarded embeds, the fixed-to-absolute rewrite, dropped Base64 images. If a detail vanished, it is usually named here.
- The structure map shows the Elementor tree beside a live preview, with the two highlighting each other on hover. Anything that came across as a red HTML-widget block had no native equivalent — hover it and you will see exactly which part of the page it was.
Between them, the question stops being “why does this look different” and becomes “this specific element was handled this specific way”, which is a two-minute fix instead of an afternoon.
The honest summary
Structure, text, images, icons, colours, spacing and typography convert well. Behaviour, integrations, anything not present in the DOM, and anything that depends on files or data living on the source server do not. Plan for a short post-import pass covering forms, menus, hover states, animations and fonts, and the process becomes predictable rather than surprising.