Elementor has two layout modes for a Container: Flexbox and Grid. Which one you get is decided by the display value the browser actually computes for your element — not by class names.
display:flex → Flexbox Container
The converter carries over the properties that matter: direction (row/column), wrap, justify-content, align-items and the gap. So a horizontal card row built with flexbox arrives as a Container with Direction = row and the same gap you had in CSS.
display:grid → Grid Container
Grid layouts become a Grid Container, and the editor labels them Grid in the Structure panel with the grid icon. Columns, rows, gaps and the item alignment options come across.
Equal columns stay as fr
This one is worth understanding. The browser resolves grid-template-columns: repeat(5, minmax(0, 1fr)) into concrete pixels — something like 241.597px 241.597px 241.604px …. Notice the tiny sub-pixel differences. If a converter compared those strings naively it would decide the columns are unequal and write fixed pixel widths, which would stop your grid from being responsive.
Instead, the columns are compared numerically with a tolerance, so near-identical tracks are recognised as equal and written as N fr — a real responsive grid that reflows as the container resizes. Genuinely uneven tracks (for example 2fr 1fr) are preserved as a custom template.
Rows size to content
Rows are set to auto rather than Elementor’s default of equal-height rows, so cards of different text lengths keep their natural heights instead of being stretched to match the tallest one.
Widths, padding and the centering trap
A very common pattern is a centered content column: max-width: 760px; margin: 0 auto;. Here the browser resolves auto into a real pixel value that depends on the current viewport — at one width it might report 260px on each side.
Writing those pixels into Elementor would break the centering the moment the screen size changed. So a block with a max-width and symmetric auto margins is detected as auto-centered and expressed the Elementor way instead: Content width = Boxed with your max-width, which centers natively at any screen size. The resolved side margins are discarded.
Column counts are measured at each breakpoint, not guessed
A grid that shows four columns on desktop and two on tablet is not one layout that shrinks — it is different values at different widths, and a converter that only looks at the desktop rendering will miss the rest.
So the page is measured more than once. The layout is re-read at each breakpoint width and the column count for that width is written into Elementor’s own responsive field for that device. In the default setting that means two extra passes, at 1024px and 767px, matching Elementor’s stock tablet and mobile breakpoints.
Turn on extended breakpoints and it measures five: laptop at 1366px, tablet-extra at 1200px, tablet at 1024px, mobile-extra at 880px and mobile at 767px. Only use that if you have those breakpoints enabled in your Elementor site settings — writing values for devices that are switched off just adds noise you have to scroll past later.
Hidden elements are hidden, not deleted
Elements computing to display: none or visibility: hidden are a small trap. They are invisible, so it is tempting to assume a converter should skip them — but a mobile-only menu, an off-canvas panel or a modal that is closed by default is invisible at the moment of conversion and still part of the design.
They convert, and get Elementor’s hide on desktop responsive flag instead of being dropped. The content survives; you decide afterwards whether it belongs. If something you expected is missing from the canvas, check the responsive visibility toggles before assuming it was lost.
Layouts with no mapping at all
Three source patterns have no Elementor equivalent, and it is better to know before you convert than after:
- Float-based layouts. Nothing reads floats, because Elementor containers have no concept of them. An old two-column layout built with
float: leftconverts as stacked blocks. It is the clearest signal that markup predates flexbox and is worth modernising at the source. - Table layouts. Same story — a layout table is structure, not design, and it arrives as nested blocks rather than columns.
- Named grid areas.
grid-template-columnsconverts;grid-template-areasdoes not, because Elementor’s Grid has no named-region equivalent. Children fall back to source order.
Picking the right mode after import
Nothing about the conversion is final. A Container’s layout mode is a dropdown in Elementor, and switching it keeps the children — so if a section came across as Flexbox and you would rather manage it as a Grid, change it and set the columns. Two rules of thumb:
- Grid when children should line up in both directions — card decks, feature matrices, image galleries, anything where you care that row two aligns with row one.
- Flexbox when children flow in one direction and sizes are content-driven — nav bars, button groups, a heading beside a badge, media-object rows.
The converter picks whichever matches the source, which is the right default. But source markup is often the result of habit rather than a decision, and a layout built with flexbox because the author always uses flexbox may well be a grid.
Practical tips
- Prefer
gapover margins between grid/flex children — gaps map cleanly, per-child margins do not. - Use
max-width+margin:0 autofor centered sections; it converts to a Boxed container correctly. - Avoid mixing floats with flex/grid. Floats have no Elementor equivalent and will need manual work.
- If a row must not wrap on mobile, set that in Elementor after import — responsive wrap behaviour is easier to tune there.
- Match your extended-breakpoint setting to what is actually enabled in Elementor, or you will get responsive values for devices your site does not use.