Open a page you built a few years ago and the panel offers Section, Inner Section and Column. Open a site set up last month and those are gone, with Container in their place. Both are Elementor, both are current, and the layout tools behave in completely different ways.
That is why this question refuses to go away. Most existing Elementor sites were built with sections and columns, most new ones are not, and anyone looking after both has to hold two models in their head.
By the end of this you will know what changed underneath, what the container controls do if you have never written CSS, how the converter behaves on a real page, and when leaving a working page alone is the right answer.
Before you start
Work out which model your site is on. In WP Admin go to Elementor > Settings > Features and look for Flexbox Container. If it is active, Section and Column are hidden and everything new you drop on a page is a container. If not, you are on the old model.
Since Elementor 3.16, flexbox containers have been active by default on new sites, which is why a recent site has no Section element at all. Older sites were left alone, and switching the feature off is not a repair for a site that already has containers on it.
Take a full backup and work on staging. Conversion runs one way: nothing turns a container back into a section, so your only route back is a backup or an old revision. This is exactly the sort of change that looks fine in the editor and wrong on a phone.
Step 1: What sections and columns actually were
The old model had three fixed levels. A section was the full-width band. Inside it sat one or more columns, side by side, with widths set as percentages. Widgets went inside columns. A row within a row meant an inner section, and you were allowed exactly one per column.
Two problems followed. The first was markup: each layout level rendered as two nested div elements, an outer one and an inner content wrapper. Elementor’s own documentation puts a single-column section at four div elements around the widget, where the equivalent container needs two. Across twenty bands, that is a genuinely heavier DOM for the browser to build and style.
The second was direction. Columns only ran horizontally and content inside a column only stacked vertically. Anything deeper than one inner section could not be built, so people faked it: odd width percentages, negative margins, custom CSS holding the alignment in place. Every one of those breaks later.
Step 2: What a container is
A container is one element that replaces all three. It holds widgets, it holds other containers, and it decides how its children are arranged using CSS flexbox.
That last part is the whole change. Flexbox is a browser layout system that lets a parent arrange its children along an axis. Elementor stopped inventing its own mechanism and exposed the browser’s in the panel instead. Set Direction to Row and the container gets flex-direction: row. No translation layer, which is why the controls stop surprising you once they click.
So the markup gets shorter, one wrapper rather than a section plus a column, and nesting stops being limited, because a container inside a container is just another container. Inner sections have no reason to exist.
Step 3: The controls that do all the work
Select a container and open the Layout tab. The Container group covers the box itself: Content Width (Boxed keeps the contents to a set width and centres them, Full Width spans the screen) and Min Height. The Items group is where the layout happens, and guessing at these is why people give up on containers.
Direction sets which way the children line up. Row puts them side by side. Column stacks them top to bottom. The two reverse options do the same in the opposite order. Everything else depends on this, so decide it first.
Justify Content distributes the children along the direction you just chose. With Direction set to Row this is horizontal spacing: push everything left, push it right, centre it, or spread it out with Space Between (equal gaps between the items, none at the ends), Space Around or Space Evenly. With Direction set to Column, the same control moves things up and down instead. That reversal confuses everyone once. The control always works along the direction of flow.
Align Items handles the other axis, the one across the flow. With Direction set to Row, Align Items is your vertical alignment: top, bottom, centre, or Stretch, the default, which makes every child as tall as the tallest. Stretch is what lines a row of three cards up neatly at the bottom without a height setting anywhere.
Worth memorising: Justify Content moves things along the direction, Align Items moves them across it.
Gap is the space between children. It applies only between them, never around the outside, which is the difference between Gap and padding. Before flexbox, spacing a row of cards meant a margin on each one and then cancelling the one on the end. Set Gap once on the parent and every child obeys it.
Wrap decides what happens when the children no longer fit on one line. No Wrap, the default, squashes them in. Wrap lets the overflow drop onto a new line, turning a row of six logos into a tidy three-by-two grid on a tablet. Turn Wrap on and Align Content appears, spacing those lines the way Justify Content spaces items.
That is genuinely the lot. Everything else in a container is styling.
Step 4: Nesting, without inner sections
A card row shows what the old limit cost you. Outer container, Direction Row, Gap 24. Inside it, three containers, each Direction Column, holding an image, a heading, some text and a button. Each card stacks, the three sit side by side, and because Align Items defaults to Stretch they are all the same height with no fixed height value anywhere. The old way needed a section, three columns, then an inner section per column or a stack of margins doing the spacing by hand.
One habit worth forming: rename your containers. Right-click and call it “Pricing row” or “Hero copy”. Four levels deep, a readable navigator saves more time than any layout control.
Step 5: How containers behave responsively
Direction, Justify Content, Align Items, Gap and Wrap all have the device switcher beside them, so each can differ per breakpoint. That is the practical win over columns, where responsive behaviour meant setting a width per device and hoping.
The usual pattern is one setting: Direction Row on desktop, Column on mobile. Everything that sat side by side now stacks, in source order, with the same Gap between items. No width percentages, no reversed stacking to fix afterwards. Where you want a different order on small screens, Column Reverse gets you there without touching the markup, though use it deliberately, since screen readers follow the source rather than the visual order.
Step 6: Converting an existing page
Elementor ships a converter, and it beats rebuilding by hand for most pages. Hover the section and click the Edit Section handle to select it. In the panel open Layout and click Convert. Elementor builds a container version and places it directly below the original, leaving the original untouched. Nothing is destroyed at that moment, which is what makes it safe to try. Compare the two on the canvas, fix what moved, then delete the original and hit Update.
Do that one section at a time. There is a page-level option that converts the whole page at once, and while it works, you are then comparing a page against a memory rather than a section against the thing above it.
What the converter does not carry over cleanly
Structure translates well, styling approximately. Check these every time:
- Percentage content widths. A content width set as a percentage may not process properly, so set it on the container by hand.
- Padding and margins. These do not always convert smoothly. If elements are not where they were, look here first, and check whether Gap should be doing that spacing job now.
- Minimum height. A container can inherit the section’s minimum height even where it was switched off. If a converted band is mysteriously tall, clear the Min Height value.
- Vertical alignment. Column vertical alignment and container Align Items are not the same control, so anything relying on the old setting needs eyeballing.
- Your custom CSS. This bites hardest. Anything written against
.elementor-column,.elementor-inner-sectionor a column width class stops matching, because those elements have gone. - Third-party addon widgets. An addon positioned relative to a column wrapper may not survive. Test each one.
When not to convert
A working page is worth something, and these are the cases where I leave it alone.
The page works and nobody is touching it. Conversion costs your time and risks a visual regression, and buys a slightly lighter DOM. On a page getting fifty views a month, that trade is not worth making.
The page carries heavy custom CSS written against column selectors. Converting then means rewriting the CSS as well as checking the layout, which is a rebuild wearing a disguise. The same goes for a page from a template or theme demo you still update: convert it and you are off that update path.
And if the site is due for replacement anyway, converting layouts on the way out is work you throw away. Put it into the rebuild instead, where you get containers and a current design for the same effort.
Where this is heading
Containers are not a fashion that might pass. Elementor 4.0, which arrived earlier this year, builds its Atomic Editor on the same idea: the atomic elements for structure are a Div Block and a Flexbox Container, with a unified Style tab and per-device control on every property.
A few facts worth being precise about, because there is noise around this. Atomic features are enabled by default on new installations, and Elementor has said new sites run version 4 by default from April 2026. Nothing migrates automatically, so updating an existing site changes nothing about your pages; the only visible difference is a notice about the Atomic Elements section at the top of the panel, which you activate or dismiss. V3 widgets and V4 atomic elements work on the same page, and you can toggle the lot at the Atomic Editor tab in Elementor > Settings (Elementor has been reorganising its menu, so some builds list it under Editor > Settings instead). Elementor has published no end-of-support date for V3, so anyone telling you your sections expire on a given date is guessing.
So converting is not work you will have to undo, and the flexbox concepts are the ones V4 uses anyway.
How to check it worked
Open the page on the front end, not the editor, and clear your cache first. Elementor stores generated CSS per page and a stale file will show you the old layout.
Resize down to a phone width and watch the bands stack, looking for anything that stays side by side and squashes. Then open the inspector on a converted band and confirm you are seeing one container wrapper rather than a section plus a column. If the old column classes are still there, the converted copy is below and undeleted.
When it does not work
The converted band is taller than the original
Almost always the inherited minimum height. Select the container, open Layout and clear Min Height. Containers pick this up even where it was switched off on the section.
Everything stacked vertically after converting
The container’s Direction is set to Column. Sections had no such setting because horizontal was the only option, so the converter has to choose, and a single-column section legitimately becomes a Column container. Set Direction to Row.
The layout is right but the styling is gone
Your CSS was targeting .elementor-column or a column width class and those elements no longer exist. Open the inspector, see which classes the element has now, and rewrite the selector against the container or a class you add yourself. Do it properly rather than with !important; the next person to touch it is you.
Common questions
Can I use sections and containers on the same site?
Yes, and on the same page. Existing sections keep working, keep rendering and keep being editable. Nothing forces you to convert on any timetable.
Can I convert containers back into sections?
No. There is no reverse conversion. Your route back is a backup or a page revision, which is the reason for doing this on staging.
Is my old site slow because it uses sections?
Partly, at most. A heavier DOM is a real cost and containers reduce it, but on most sites the bigger numbers are images, render-blocking scripts and plugin bloat. Measure before you attribute it, and if the page is genuinely slow, speed work will find more than a conversion does.
Where did the Inner Section widget go?
It is hidden once flexbox containers are active, because a container inside a container does the same job without the one-per-column limit. Existing inner sections carry on working.
What to actually do with this
Elementor replaced a rigid three-level structure with a single element that speaks the browser’s own layout language. Fewer wrappers, unlimited nesting, and five controls, Direction, Justify Content, Align Items, Gap and Wrap, that between them handle nearly every layout you will build.
For existing sites the plan is unglamorous. Convert pages you are editing anyway, one section at a time, on staging, checking min height, padding, vertical alignment and any CSS that named a column. Leave the rest. Elementor 4 confirms the direction rather than changing it, so the effort goes with the grain.
Where I would not spend that effort is a site due for replacement, or one held together by CSS written against column classes. There, converting is a rebuild with extra steps and is better done as one. If you cannot tell which you have, get in touch and I will tell you straight.
