Elementor Container vs Section: Which Should You Use?
Use containers. Elementor’s flex containers replaced the old Section/Column structure in Elementor 3.6 and are now the default and the actively developed layout system — sections and columns are legacy and are kept only so older sites keep working. A container produces roughly half the wrapper markup of a section-and-column stack, maps one-to-one onto Figma auto-layout, and gives you direction, gap, wrap, align and justify controls that columns never had.
The only reason to still touch a section is that you inherited a site built with them and a full conversion isn’t worth the risk. Below is the actual difference, what breaks when you convert, and how to decide per page rather than per site.
What changed between sections and containers
The old model was rigid: a Section held Columns, Columns held widgets, and nesting anything else meant an inner section — a third wrapper. Column widths were percentages of a 12-point grid, vertical alignment was a single setting, and there was no gap property, so spacing was done with padding and negative margins.
A container is a single element with CSS flexbox on it. It holds widgets or other containers, with no fixed hierarchy, so what used to need Section → Column → Inner Section → Column is one container holding two containers.
The markup difference, concretely
A two-column row with the legacy structure renders roughly:
section→.elementor-container→.elementor-column→.elementor-widget-wrap→ widget
That’s four wrapper elements before you reach content, repeated for every column. The same row as containers renders:
.e-con→.e-con-inner→ widget
Two wrappers. On a page with fifteen rows the difference is a few hundred DOM nodes, which shows up in style recalculation time and in how long the browser spends on layout — the two things that move Total Blocking Time on a builder-heavy page.
Controls containers have that columns don’t
- Direction — row or column, per breakpoint. A card list can be a row on desktop and a column on mobile without any width overrides.
- Gap — real flex gap, so spacing between items doesn’t require padding maths or negative margins.
- Wrap — items reflow onto a new line automatically when they run out of room.
- Justify and align — both axes, independently, instead of one vertical-alignment dropdown.
- Grow and shrink on individual children, which is how you build a sidebar that holds its width while the main column takes the rest.
Why containers match Figma
Figma auto-layout is flexbox with different words on the controls. A vertical auto-layout frame is a column container; item spacing is gap; “fill container” is grow; “hug contents” is auto width. That makes a Figma to Elementor conversion close to mechanical when both sides use the same model — and a guessing exercise when the build side is columns and percentages.
When sections are still the right call
Three honest cases:
An existing site with dozens of section-built pages. Converting is not a toggle — it rewrites the layout data. Budget time to re-check every page rather than doing it on a Friday.
A third-party template or theme built on sections. Its CSS often targets .elementor-column classes. Converting breaks that styling and you own the repair.
A plugin that requires them. Some older add-ons still assume the section markup. Check before you convert, not after.
For anything new, there is no case for sections.
How to convert an existing page safely
- Back up the database — not just the page. Elementor layout lives in post meta, and a page’s revision history will not always save you.
- Convert one page first, ideally a low-traffic one, and keep it as your reference for what breaks.
- Right-click the section → Convert to container. Elementor keeps the content and maps the structure; it does not always map the spacing.
- Re-check padding, margin and gap on every converted row. This is where the visual drift happens.
- Check every breakpoint. Column percentage widths become flex-basis values that behave differently when they wrap.
- Delete the leftover negative margins. They were compensating for column padding that no longer exists.
Does converting to containers improve performance?
Yes, but it is not a headline fix. Fewer DOM nodes and less CSS mean faster style and layout work, which helps Total Blocking Time and interaction responsiveness. It does almost nothing for your largest real costs, which on most Elementor sites are unoptimised images, Google Fonts loaded in more variants than the design uses, and third-party embeds pulling in scripts you never asked for. Fix those first; treat the container conversion as structural hygiene that also happens to be a little faster.
FAQ
Are Elementor sections deprecated?
Effectively, yes. Flex containers became the default layout element in Elementor 3.6, and new development goes into containers. Sections still render and still work, so existing sites are not at risk, but Elementor is no longer adding capability to them.
Should I convert my existing Elementor site to containers?
Only if you have time to check every page afterwards. Converting rewrites layout data, and spacing rarely carries over cleanly. For a live site with dozens of pages, convert as you touch each page rather than in one sweep.
Will converting to containers break my site?
It can change your spacing and your responsive behaviour, and it will break CSS written against .elementor-column classes. It does not lose your content. Take a database backup and convert one page at a time.
Can I use containers and sections on the same page?
Yes. They coexist without conflict, which is what makes gradual conversion practical. Mixing them on the same page makes spacing harder to reason about, so where possible convert a whole page at once.
Are containers faster than sections?
Modestly. A container row emits about half the wrapper markup of a section-and-column row, so pages have fewer DOM nodes and less CSS to resolve. The gain is real but much smaller than what you get from optimising images, fonts and third-party scripts.
What is a nested container in Elementor?
A container placed inside another container. It replaces the old inner-section pattern and has no depth limit, so a three-level layout no longer needs three different element types.