Converting a container to a column in WordPress means one of two very different things, and which one you need depends on the editor you are using. In Elementor, Containers replaced the old Section/Column structure in version 3.6, and switching a section to the new structure is a right-click away — while going back the other way has no button at all. In the block editor, “container” is a Group block and “column” is a Columns block, and the conversion is a layout change rather than a structural one.
This guide covers both editors, what actually changes underneath, and the four things that break on almost every conversion: vertical stacking, lost spacing, mobile order, and nested depth.
Key takeaways
- Elementor: right-click the section handle ? Convert to Container. It preserves your widgets and is one-way; duplicate the section first if you might change your mind.
- Block editor: there is no “convert” command. You change the Group block’s layout to a row, or drop a Columns block and move content into it.
- A container is a flex parent; a column is a flex child. That is why conversion changes direction, wrapping and spacing behaviour, not just markup.
- On Elementor 4.x, Containers are the supported structure. Converting a container back to columns is going backwards — rebuild only if a plugin or template requires it.
Container vs column: what the words actually mean
Both editors use the same CSS model, which is what makes the vocabulary confusing.
- A container is a flex parent. It has a direction (row or column), alignment, gap and wrapping, and it holds items.
- A column is a flex child inside a row. Its width is a share of the parent, and it usually holds other elements.
So “container to column” is really “parent to child”. In the old Elementor structure you had a Section (a row), which held Columns (children), which held Widgets. In the current structure you have a Container that can hold widgets directly, or hold other Containers — a column is no longer a separate thing you place, it is a container set to a fixed width inside a row-direction parent.
That is the whole reason Elementor pivoted: one flexible element instead of three rigid ones. It is also why tutorials that promise a “convert back to column” button are describing something that does not exist.
| Term you are using | Elementor (3.6+) | Elementor (legacy) | Block editor |
|---|---|---|---|
| Container | Container element — flex parent, can hold widgets or other containers | Section | Group block |
| Column | Child Container with a width, inside a row-direction parent | Column inside a Section | Column block inside a Columns block |
| Row | Container with Direction: Row | Section (structurally a row) | Group with a row layout |
| Gap between items | Container Gap setting | Column margins | Block spacing support |
Elementor: converting a Column structure to a Container
If you are on an older page built with Sections and Columns (Elementor 3.5 or a template imported from that era), you can convert the whole structure without touching the widgets.
- Open the page in Elementor and hover the section until the blue handle appears at the top-left.
- Right-click the handle. The context menu includes Convert to Container. (On some builds the same action is in the section’s toolbar, shown as a small container icon.)
- Confirm. Elementor rebuilds the section as a Container, moves the widgets across, and keeps the column widths as percentage widths on the children.
- Review the result on tablet and mobile. Containers default to a different mobile behaviour than columns did — this is where most pages visibly change.
- Check vertical spacing: the section’s old top/bottom padding often maps to the container’s padding, but the gap between columns becomes the container’s Gap setting, and it defaults to a value that may not match your original margins.
It is one-way. Elementor does not ship a “convert back to section and columns” action, and the conversion is saved immediately. If the page is important, duplicate it first (right-click the page in Pages ? All Pages ? Duplicate) so you have a reference copy of the old structure.
What survives and what does not
Widgets, their content, custom CSS classes and most styling transfer intact, because they are attributes of the widget, not the section. What changes is the layout model:
- Column width percentages become child widths — usually accurate, occasionally off by a fraction on three-column layouts.
- Column gaps become a single container Gap value. If your columns had different margins, those margins are now on the child containers and may double up.
- Section “content width” and “stretch section” options map onto container width settings, and full-width sections sometimes lose their stretch behaviour on the first pass.
- Background images and overlays move to the container, but overlay opacity occasionally resets — check hero sections specifically.
Elementor: going from a Container back to Columns
There is no built-in reverse conversion. You have three realistic options.
Option A: rebuild the row with containers (recommended)
Place a new Container, set its Direction to Row, set Wrap to No Wrap, and drop one child Container per column, each with a fixed or percentage width. Visually and functionally this is a column layout — it just uses the current element model, which is what Elementor supports and what future updates will keep working.
Option B: fake it with child widths
Keep the single container and drop your widgets straight into it, then set each widget’s width (Advanced ? Width, or the flex properties on the child) to 33% for a three-up row. Faster for simple layouts such as three icon boxes, but it breaks down as soon as one child needs different padding.
Option C: restore a legacy section
If a specific plugin or template demands the Section/Column structure, import a template that still uses it, or turn off Containers in Elementor ? Settings ? Features on a staging copy. Do not do this on a live site unless you have to: on Elementor 4.x the container model is the default path, and legacy sections get progressively less testing.
The manual rebuild that never breaks
When a conversion goes wrong — widgets stacked vertically, spacing collapsed, images stretched — rebuild rather than repair. It is usually faster.
- Duplicate the section or container so you keep a working copy to compare against.
- Create the target structure first: a container with direction Row and the number of child containers you need.
- Move widgets one at a time, using the navigator (the layer tree) rather than dragging on the canvas — drag targets are unreliable inside nested flex containers.
- Copy spacing across by reading the old values before you delete anything: note padding, margin and gap numbers for desktop, tablet and mobile.
- Delete the old structure last, after checking the page on a phone.
Block editor: Group, Row and Columns
In the block editor the vocabulary is different again, and there is no conversion command — you change what a Group block is.
Turning a Group into a row of columns
- Select the Group block that wraps your content.
- In the block toolbar or the sidebar’s Layout panel, switch the layout to a row. The Group block’s layout controls set direction and whether children wrap.
- If the children need equal widths, select each one and set its width, or use the Columns block instead — it exists precisely for fixed multi-column rows.
- To move existing blocks into a Columns block, use the block list view (the outline icon in the toolbar): drag blocks into the column containers there, where the drop targets are explicit.
Turning columns back into a single container
Select the Columns block, open its toolbar menu and choose Group — the columns become a single Group containing the same inner blocks in sequence. From there you can set a row layout again if you need the horizontal arrangement without the rigid column widths.
Where the block editor differs from Elementor
WordPress stores block structure as HTML comments in the post content, so a layout change is a markup change. That has one important consequence: the block editor will not silently convert content it does not recognise. Legacy or pasted HTML sits inside a Classic or HTML block, and no layout control applies to it until you convert it to blocks first.
What breaks, and how to fix it
Everything stacks vertically after conversion
The container’s direction is Column instead of Row. Set Direction to Row, and check that Wrap is off — with wrapping enabled and children wider than 100%, each child drops to its own line, which looks identical to a stacking bug.
Spacing collapsed or doubled
Old column margins are now child margins inside a flex parent that also applies a gap. Pick one mechanism: either set the container gap and remove child margins, or keep margins and set gap to zero. Mixing both is what produces the “double spacing” look.
Mobile order is wrong
Containers let you reorder children per breakpoint, but the conversion does not preserve the old column order. Check the mobile view and set the order explicitly on the children rather than relying on document order. If the layout still misbehaves on small screens, the theme’s own responsive CSS may be involved — diagnosing mobile layout problems covers that separately.
Nested containers three levels deep
Every conversion adds a level of nesting, and each level adds DOM nodes and CSS. If a hero section ends up five containers deep, flatten it: most designs need two levels — an outer container for width and an inner row for the items.
The page got slower after converting
Deep nesting plus per-container custom CSS is the usual cause. Elementor 4.x generates fewer wrappers than the section/column era, so a conversion should not slow a page down on its own — if it did, look at what you added during the rebuild rather than the conversion. General page speed work applies here.
When you should not convert at all
Two cases where the answer is “leave it alone”.
A page that already works on containers. Converting to columns is downgrading. Elementor’s roadmap, documentation and new templates all assume containers, and legacy sections receive less testing with each release.
A theme that controls the layout for you. If you are using a block theme or a theme with its own layout system, structural changes belong in the theme’s templates, not in the page. Editing a theme’s layout safely is a separate skill — customising a WordPress theme covers the child-theme route so your changes survive updates.
Frequently asked questions
How do I convert a container to a column in Elementor?
You cannot convert a container into a legacy Column, because Elementor removed that element from the default structure in version 3.6. What you can do is place child containers side by side: create a Container, set Direction to Row with Wrap off, then add one child Container per column and set each child’s width. The reverse direction — Section to Container — is a single right-click action called Convert to Container.
Is converting a section to a container reversible?
Not with a button. Elementor does not include a “convert back to section” action, and the change is saved as soon as you confirm. Duplicate the page before converting if you may need the old structure, or rebuild it manually using child containers set to percentage widths.
Will converting break my custom CSS?
Custom CSS attached to widgets survives, because it targets the widget’s class or your own selector. CSS that targeted the section or column wrapper classes will stop applying, because those wrappers no longer exist. Search your custom CSS for .elementor-section and .elementor-column before converting — those are the selectors that break.
Why did my columns turn into a vertical stack?
The parent’s flex direction is column, or wrapping is enabled and the children are wider than the container. Set the direction to row and switch wrapping off, then check each child’s width. This is the most common post-conversion issue and it is a setting, not a bug.
How do I do the same thing in Gutenberg?
Use a Group block with a row layout for a flexible row, or the Columns block when you need equal fixed columns. There is no direct converter between the two: to move content, use the block list view to drag blocks into the new structure. Converting the Columns block to a Group collapses it into a single container and preserves the inner blocks.
Does converting affect SEO?
Not directly — the visible content and text stay the same, so rankings do not depend on which structural element wraps them. It can affect Core Web Vitals indirectly: fewer wrappers and less CSS generally means a faster page, while deeply nested containers can hurt layout stability. Check the page in PageSpeed Insights after the conversion rather than assuming.
The short version
Sections convert to containers with one right-click and no going back; containers become columns by setting a row direction and giving the children widths. In the block editor the equivalent is changing a Group’s layout or moving content into a Columns block. In both editors, verify direction, wrapping and gap before you touch anything else — those three settings account for nearly every “the conversion broke my layout” report.