Elementor Flexbox Containers

A container is a single flexbox-based element that can hold widgets or other containers directly, replacing the old pairing of a section wrapping columns. That collapses three layers of nested markup — section, inner column, widget wrapper — into one, and most of what changed in Elementor's layout system over the past few years follows from that one simplification.

From sections and columns to one element

The older model built every layout from a section containing one or more columns, each column a fixed-width or percentage-based box that widgets sat inside. It worked, but it produced heavy, deeply nested markup, and it enforced a rigid row-of-columns shape that made asymmetric or overlapping layouts awkward to build without workarounds.

A container drops that structure in favour of a single element governed directly by flexbox properties. Widgets can sit straight inside a container with no intermediate column wrapper, and a container's own layout settings — not a parent-child pair of section-and-column settings — control how its contents are arranged. The result is lighter markup and a layout model closer to how CSS actually works, at the cost of everyone who learned the old model having to learn the new one. Containers are part of the core, free plugin rather than a paid addition — see Elementor free versus Pro for where the actual tier line sits — and lighter markup is one of the reasons this change matters for how to speed up Elementor, since every extra wrapper is more DOM for the browser to parse.

Direction, justify, align, gap

A container's layout panel exposes the same concepts flexbox itself uses, under approachable names:

Because these map directly onto CSS flexbox, custom CSS layered on top behaves predictably — you are not fighting an abstraction on top of an abstraction the way column widths sometimes felt in the old model.

Nesting containers

A container can hold other containers, and those can hold further containers still. This is what actually replaces the rigid section-and-column shape: instead of one row of fixed columns, you build a tree of containers, each with its own direction and alignment, as deep as the layout needs. A hero section might be a column-direction outer container holding a row-direction container for a badge and heading, nested inside a wider full-width container — each widget inside pulling its color and type from Global Colors and Fonts rather than one-off values — all achievable without the workarounds the old model needed for anything beyond a simple row. A site header with a logo on one side and a nested row of menu and buttons on the other, as in how to edit a header in Elementor, is a common real case for nesting like this, and the same tree-of-containers approach scales up to a full mega menu when a header needs one. For more layout patterns built this way, Elementor examples is worth a look, and the general trade-offs of building with any drag-and-drop system are covered in what a WordPress page builder actually is.

Converting old sections

Elementor provides a conversion tool that turns an existing section-and-column layout into containers. What commonly breaks in that process:

• Custom CSS written against old class names. Selectors targeting section, column or inner-section classes stop matching once those elements are gone, and need rewriting against the container's own structure.
• Pixel-precise layouts relying on old column-width percentages. Flexbox distributes space differently, and a layout that depended on exact column math can shift.
• Third-party scripts expecting the old markup. Anything that queried the DOM for section or column elements directly, rather than through Elementor's own APIs, stops finding what it expects.
• Responsive behaviour at specific breakpoints. The old model and the container model do not always collapse to mobile in visually identical ways, so breakpoints are worth re-checking after converting.

Duplicate the page or export the template before converting, since reconstructing the original section-and-column structure afterwards is not straightforward.

Why old templates still work

Elementor kept full rendering support for sections and columns rather than deprecating them outright, so a page, a saved template, or an imported kit built entirely the old way continues to display correctly with no action required. The two systems can also coexist on the same page — a legacy section above a newly built container section, for instance — which is what makes migrating a large site gradual rather than all-or-nothing.

When to keep the legacy layout

Converting is not free, and it is not always worth doing. A site with substantial custom CSS tied to the old class structure, or one built from imported kits and templates that assume sections and columns, carries real regression risk for a change that may bring no visible benefit to visitors. Keep the legacy layout in place when the page already does what it needs to, and reserve container-based rebuilding for new pages, redesigns, or layouts the old model genuinely could not express well — asymmetric grids and deeply nested arrangements chief among them.

Common mistakes

• Converting a large, complex page without a backup first. The conversion is difficult to reverse cleanly.
• Assuming old custom CSS carries over unchanged. Selectors tied to section and column classes need rewriting.
• Fighting the container for a layout the old columns handled fine. Not every page needs converting.
• Ignoring gap in favour of manual widget margins. It duplicates spacing logic and makes later edits inconsistent.
• Nesting containers more deeply than the layout actually requires. Extra nesting adds markup back that containers were meant to remove.
• Skipping a responsive check after converting. Breakpoint behaviour can differ from the original section-based layout.

Verify

Open a converted page on desktop and mobile and compare it against a saved screenshot or the original before conversion. Check that gap, alignment and direction match what the old columns produced, then inspect any custom CSS in the browser's developer tools to confirm it is still matching real elements rather than silently doing nothing.