Elementor quietly rewired how every page on your site gets built. For years, Elementor pages were made of Sections that held Columns that held Widgets - a three-level nesting scheme borrowed almost directly from old-school HTML table layouts. Containers replaced that with a single, infinitely nestable Flexbox element. It sounds like a small technical footnote. In practice it changes how you should think about building a page, and it explains why some sites feel noticeably snappier after a rebuild while others end up with a tangled mess of nested boxes that’s harder to maintain than the Sections it replaced.
This piece goes past the marketing description and into the mechanics: what a Container actually is in the DOM, why Flexbox (and now Grid) changes your options, where teams get bitten during migration, and a concrete decision framework for when Sections are still the pragmatic choice.
What a Container Actually Is
Under a Section/Column layout, Elementor rendered something close to this for a simple two-column row:
<section class="elementor-section">
<div class="elementor-container">
<div class="elementor-column">
<div class="elementor-widget-wrap">...</div>
</div>
<div class="elementor-column">
<div class="elementor-widget-wrap">...</div>
</div>
</div>
</section>Four wrapper levels before you reach a single widget. A Container collapses that into one element that is, by default, a Flexbox context:
<div class="e-con e-con-full">
<div class="e-con-inner">
...widgets or nested containers directly...
</div>
</div>A Container can hold widgets directly, or hold other Containers, at any depth. There is no longer a hard distinction between “the thing that holds columns” and “the thing that holds widgets.” That single change is what makes Containers flexible: you can build a hero section that is itself a horizontal Container, containing a vertical Container for text stacked on top of a CTA row, sitting next to an image Container - three levels of real nesting, expressed with one element type instead of three.
Flexbox First, Grid Since 3.16
The original Container release used Flexbox exclusively: display: flex, with controls for direction, justify-content, align-items, and gap mapped directly onto Elementor’s UI panel. Since Elementor 3.16 you can switch a Container’s display mode to CSS Grid, which changes the available controls to grid-template-columns, grid-template-rows, and explicit item placement. That matters because Flexbox is a one-dimensional layout model - it’s excellent at distributing items along a single row or column but gets awkward when you need true two-dimensional alignment (think a pricing table where every row and column has to line up independently). Grid Containers close that gap without needing a third-party plugin or custom CSS.
The practical rule of thumb: reach for Flexbox Containers when you’re arranging a sequence of items along one axis (a card row, a stacked hero, a button group). Reach for Grid Containers when you need a genuine matrix - equal-height cards across rows and columns, a magazine-style layout, or a dashboard-like grid of widgets.
Browser Support and Fallback Behavior
Flexbox has been reliably supported across every modern browser for long enough that it’s a non-issue for the overwhelming majority of production sites - Chrome, Firefox, Safari, and Edge have all supported the full Flexbox spec since well before Elementor introduced Containers. CSS Grid support followed a similar trajectory and is equally safe to rely on today. The one legacy concern worth naming directly: Internet Explorer 11 supports an older, buggy, and incomplete implementation of Flexbox, and effectively no support for modern CSS Grid. Elementor dropped meaningful IE11 support well before Containers launched, so if your site still has a genuine business requirement to support IE11 - increasingly rare, but not zero for certain enterprise, government, or legacy-industry audiences - that requirement needs to be resolved independently of the Container decision, since neither Sections nor Containers render acceptably on IE11 at this point. For every other audience, Flexbox and Grid Container support is a solved problem, not a real migration risk, and any lingering hesitation about “newer CSS not being safe yet” is outdated advice that stopped being true years ago.
Where the DOM Reduction Actually Pays Off
Fewer wrapper elements isn’t just a tidiness argument. Each nested div is a node the browser has to lay out, style, and paint, and each one is a node your CSS selectors and JavaScript have to traverse. On a landing page with forty or fifty Section/Column blocks, that four-level nesting adds up to hundreds of extra DOM nodes with no content in them - pure structural overhead. Lighthouse and Core Web Vitals audits penalize excessive DOM size (Google’s own guidance flags pages over roughly 1,500 nodes), and a Section-heavy Elementor page can hit that ceiling surprisingly fast once you count Elementor’s internal wrapper markup.
Containers don’t eliminate wrapper markup entirely - each Container still renders an outer element and an e-con-inner wrapper - but they remove one full nesting level compared to the old Section > Container > Column chain, and because a Container can hold widgets directly, you often skip the “empty column that exists only to hold one widget” pattern that was extremely common under the old system. In real rebuilds this typically shows up as a meaningfully smaller DOM and a small but measurable improvement in Cumulative Layout Shift, because Flexbox’s alignment properties resolve final positions more predictably than the old column width percentages combined with padding.
A concrete before/after is worth walking through. Take a fairly typical marketing homepage built the old way: hero, three feature Sections each with two or three Columns, a testimonial Section, a pricing Section with three Columns, and a footer CTA Section - eight top-level Sections, roughly twenty Columns, and somewhere around 45-60 empty wrapper divs once you count every elementor-container and elementor-widget-wrap in between. Rebuilt as Containers with sensible flattening - a horizontal Container per feature row instead of a Section-plus-two-Columns pattern - the same page typically lands closer to 20-25 wrapper elements for the same visual result. That difference alone can move a borderline DOM-size Lighthouse warning to a clean pass, without touching a single image or font.
The Migration Pitfalls Nobody Mentions
Switching an existing site from Sections to Containers is not a background process you flip on. Elementor deliberately keeps both systems running side by side so old pages don’t break, which means the migration is manual, page by page, and a few things catch people out:
Widget-specific CSS that targeted .elementor-column. If a theme or a custom CSS snippet styled columns directly by class, that selector has nothing to attach to once the page is rebuilt with Containers - the class doesn’t exist in the new markup. Audit any custom CSS in the Elementor Custom Code panel or your child theme before converting a page that has manual styling layered on top of it.
Responsive behavior isn’t a straight port. Column widths in the old system were percentage-based and collapsed to full width on mobile by a fixed breakpoint rule. Flexbox Containers use flex-wrap and per-breakpoint direction controls, which give you more control but also mean your old mobile stacking order isn’t guaranteed to carry over automatically - check every breakpoint after conversion, not just desktop.
Nested Sections inside Columns become nested Containers, and nesting depth has a real ceiling. Elementor doesn’t hard-block deep nesting, but past four or five levels the visual editor gets noticeably slower to render, and site visitors on lower-end devices will feel it in scroll and interaction responsiveness. If your old page had Sections nested inside Columns inside Sections (a common pattern for complex hero areas), flatten that structure during the rebuild rather than mechanically converting each old nesting level into a new Container.
Screen reader order can silently diverge from visual order. Flexbox’s order property lets you display things in a different sequence than they appear in the DOM - useful for responsive reordering, but it means a screen reader (which follows DOM order) can announce content in a different sequence than sighted users see. If you use the reorder controls to, say, put an image before its caption visually, verify with a screen reader or the accessibility tree in DevTools that the reading order still makes sense.
Third-party widgets from other plugins can render oddly inside a Flexbox Container if they were designed assuming a fixed-width Column parent. Widgets that set an explicit pixel width internally, rather than sizing themselves relative to their parent, can end up either overflowing a narrow Flexbox child or refusing to shrink at all on mobile. This is specifically worth testing with any third-party Elementor addon widgets (countdown timers, pricing tables, testimonial sliders from add-on packs) rather than assuming they were built with Containers in mind just because the plugin itself claims Container support.
A Worked Example: Rebuilding a Three-Column Pricing Table
Pricing tables are one of the clearest illustrations of why Grid Containers exist. Under the old system, a three-column pricing table was three separate Elementor Columns inside one Section, each an independent vertical stack of widgets - a heading, a price, a feature list, a button. The problem: nothing forced the feature lists in each column to align row by row. If the “Pro” plan had one more feature line than “Basic,” the buttons at the bottom of each column landed at different heights unless you manually padded the shorter columns - a fragile fix that broke again the next time content changed.
Rebuilt as a Grid Container with three explicit columns and a defined row structure (heading row, price row, feature-list row, button row, each mapped to a specific grid row), every plan’s button sits at the same height automatically, because the grid’s row-tracks - not manual padding - enforce the alignment. Adding or removing a feature line from one plan no longer requires touching the other two columns at all. This is the specific class of layout problem Flexbox structurally can’t solve on its own (it aligns along one axis, not row-by-row across a full matrix) and why Grid Containers, not just Flexbox ones, matter for anyone building tables, comparison grids, or dashboard-style layouts.
Common Visual Bugs After Conversion, and Their Actual Cause
A handful of visual regressions show up often enough after a Section-to-Container conversion that it’s worth naming them directly rather than treating each as a one-off mystery. Content overflowing its container on mobile is usually a leftover fixed-width setting on a widget that worked fine inside a percentage-based Column but doesn’t shrink inside a Flexbox child without an explicit flex-shrink or max-width rule. Vertical centering that stops working after conversion is almost always a missed align-items setting on the new Container - the old Column system vertically centered content by a different mechanism that Flexbox doesn’t replicate automatically. Buttons or images that were previously full-width on mobile but now shrink to content size trace back to Flexbox’s default sizing behavior, which sizes children to their content unless you explicitly set a width or flex-grow value - the old Column system defaulted to full width, Containers do not.
When Sections Are Still the Right Call
Despite Elementor making Containers the default for new sites since version 3.6, there are legitimate reasons not to convert an existing site immediately:
Third-party addons with Section-specific integrations. Some older Elementor addon plugins hook into the Section/Column widget structure directly rather than the generic Container API. Check your installed addons’ changelogs for explicit Container support before committing to a full rebuild.
Large sites where a full rebuild isn’t currently budgeted. Sections aren’t deprecated in the sense of being removed - they still render correctly and Elementor has committed to supporting them. A partial migration (new pages built as Containers, old pages left alone until their next redesign cycle) is a perfectly reasonable strategy and avoids introducing regressions across dozens of pages at once.
Client-trained teams who edit pages themselves. If non-technical staff maintain the site and are used to the Section/Column mental model, a wholesale switch to Flexbox terminology (justify-content, align-items, gap) has a real training cost. Weigh that against the performance gains before forcing a migration purely for technical tidiness.
Working With Client Teams Through a Migration
Agencies rebuilding a client’s site as Containers, rather than an in-house team migrating their own pages, face an additional consideration worth planning for explicitly: the client’s own editors will encounter unfamiliar terminology the first time they open a rebuilt page, even if the visual result looks identical to what they’re used to. A short, focused handoff session - walking through where justify-content and align-items live relative to the old margin and text-align controls the client previously used, and specifically calling out that gap now replaces manual spacing between widgets - heads off a wave of confused support tickets in the weeks after handoff. Documenting this as a one-page reference specific to the client’s actual common editing tasks (adding a new card to a feature row, adjusting spacing in a hero) is more useful than a generic Elementor Containers tutorial, since it maps directly onto the tasks that specific client actually performs rather than Elementor’s full feature surface.
A Practical Migration Checklist
For teams planning a genuine conversion rather than just building new pages as Containers going forward:
1. Start on staging, and convert one template at a time - don’t attempt a site-wide bulk conversion.
2. Audit custom CSS and addon plugins for Section/Column-specific selectors before touching the page.
3. Rebuild rather than auto-convert wherever the old structure has more than two nesting levels - flatten first.
4. Re-test every responsive breakpoint, not just mobile and desktop.
5. Check screen reader reading order wherever you’ve used Flexbox’s visual reorder controls.
6. Run a Lighthouse pass before and after so you have a real number for the DOM-size and CLS improvement, rather than relying on the page “feeling” faster.
Flexbox Gap vs. Margin: A Small Detail That Causes Real Bugs
One specific migration trap deserves its own callout because it’s so common: sites converted from Sections frequently end up with doubled spacing between elements. The old Section/Column system relied on padding and margin set individually on each widget to create spacing between elements in a row. Flexbox Containers instead expose a single gap property that spaces every child uniformly. If a rebuild copies over the old per-widget margins and sets a Container gap on top of them, the visual result is inconsistent, larger-than-intended spacing that’s hard to diagnose because it looks correct in isolation and only becomes obviously wrong once you compare it against the original design mockup. The fix is straightforward once you know to look for it: strip old per-widget margins during a Container rebuild and let the Container’s gap control handle spacing consistently, rather than layering both systems on top of each other.
Frequently Asked Questions
Will converting to Containers break my existing Sections on other pages? No - Elementor renders both systems independently, so converting one page has no effect on pages still using Sections. There is no site-wide switch that forces every page to migrate at once.
Do I need to convert every page, or can I mix Sections and Containers on the same site? Mixing is fully supported and, for most sites with a meaningful number of existing pages, is the pragmatic path - build new pages as Containers, leave old ones alone until their next redesign.
Does switching to Containers require a different theme? No, Containers are an Elementor-level change independent of your active theme, though a theme with clean, minimal wrapper markup of its own compounds the DOM-size benefit rather than adding its own overhead on top.
The Bottom Line
Containers aren’t a cosmetic rename of Sections - they’re a genuine architectural simplification that trades three nested element types for one, and they open up layout options (true Flexbox alignment, and Grid since 3.16) that Sections never had, on browser support that’s been solid for years. The DOM-size and CLS improvements are real and measurable, not just marketing claims, but they only materialize if the rebuild actually flattens structure instead of mechanically converting each old Section into a new Container one-for-one. Treat the migration as a chance to simplify a page’s structure, verify accessibility and responsive behavior at every breakpoint, brief any client editors on the terminology shift, and watch specifically for doubled spacing from leftover margins - and you’ll end up with something genuinely lighter than what Sections could produce, not just a renamed version of the same problem.