I was building a feature row on a client's WordPress site with Elementor v4. The layout was simple: one flex container as the row, and inside it a narrow child container for a stat card, which I set to 296px wide so it would hug the left while the rest flowed. I typed that number into the width panel, hit update, and opened the front end. The child container rendered at full parent width, roughly 850px, as if the width field I filled in meant nothing at all.
My first instinct was that some other CSS was overriding it. I opened DevTools, found the child container element, and combed through every rule touching width. Nothing was overriding it. The strange part: there was no --width rule for that element at all. It was not being overridden, it was simply never written. Yet in the editor, the 296px value was clearly saved. I checked _elementor_data to be sure, and yes, the number was in there. So the data was persisted, but the per-post CSS stayed silent about width.
Why this happens
It took me a while to realize that in Elementor v4 a container's width does not stand on its own. It is gated by another setting: content_width.
The default value of content_width is "boxed". And in boxed mode, the width field I filled in is ignored. Boxed uses different semantics: it reads boxed_width as a max-width, not a width, and the container gets an e-con-boxed class that forces width: 100%. So the 296px I typed into the width field really was saved, but it was never used to emit a --width rule, because boxed mode never looks at that field. That is why the per-post CSS was empty about width, and the container stretched to fill its parent.
Only content_width: "full" makes Elementor emit the raw --width value. As long as content_width stays "boxed", my literal width value is talking to an empty room.
There is one more layer that muddies things. If the template was ever touched in Elementor v3, a legacy _element_width sometimes lingers and adds a conflicting layer. So even after I fixed content_width, a leftover _element_width could still pull the layout the wrong way.
The fix
The fix is not to hack around it with external !important CSS. The fix is to set the container's own settings so Elementor actually writes the width rule I want. Three things I set together:
{
"content_width": "full",
"width": { "unit": "px", "size": 296 },
"_flex_size": "none",
"_element_width": ""
}The key detail here: content_width must be "full" so --width is genuinely emitted. Then width gets 296px as normal. The easy one to miss: _flex_size must be "none". This translates the child container to flex: 0 0 auto, meaning it neither grows nor shrinks to fit leftover flex space, so its width is actually respected instead of being stretched by flex-grow. And I leave _element_width empty so no leftover v3 legacy interferes.
If I genuinely want a boxed container, that is a different story: I set boxed_width, not width. But for this narrow-card case where I want a raw width, full plus width is the route.
Verifying it is simple: open the per-post CSS Elementor generates for that page and confirm --width: actually appears for that container element. If --width: is there, the layout follows. If it is still missing, content_width is still "boxed" somewhere.
The bonus gotcha: _element_width: "initial" is not enough
While tracing this, I tried a wrong shortcut. I assumed setting the legacy v3 _element_width: "initial" would be enough to "release" the width. It did not work. As long as content_width stays "boxed", the e-con-boxed class keeps forcing width: 100%, so _element_width: "initial" alone still leaves the container stretched to full width. The root cause lives in the content_width gate, not in the legacy width field. Until that gate is fixed to full, anything I tweak on the v3 layer only masks the symptom.
The takeaway
In Elementor v4, container width is not a single setting but the result of a gate. content_width decides whether your width field is even read. If your container ignores a width you clearly set, do not rush to blame some other CSS overriding it; first check whether content_width is still "boxed". Set content_width: "full", fill in width, lock it with _flex_size: "none", clear the leftover legacy _element_width, then prove it via --width: in the generated CSS. Since I understood this gate, I stopped assuming Elementor was "ignoring" my input, and started asking: is the setting I filled in actually being read in the mode that is currently active?