The report arrived over chat: "the footer is cut off on my phone". I opened the site on a handset and there it was. The page scrolled sideways, a horizontal scrollbar appeared, the footer content was clipped at the right edge, and one column had been shoved clean off-screen. On desktop: flawless. Four footer columns lined up neatly, not a pixel out of place. The site was built years ago with Elementor, long before I inherited it, so I knew I was about to dig through layers of old decisions.
A bug that only exists on mobile while desktop stays pristine almost always means one thing: some value was tuned for desktop and rode down to the small screens with it. The only question is which value.
The investigation
My first move on any horizontal overflow is the same: prove the overflow is real, then find the guilty element. In DevTools device mode, I compared the document width against the viewport:
document.documentElement.scrollWidth;
document.documentElement.clientWidth;At a 360px viewport, scrollWidth came back as 511. There were 151 extra pixels that had no business existing. A number that specific is rarely a coincidence, so I ran a quick walk to find whichever element poked past the viewport:
const limit = document.documentElement.clientWidth;
for (const el of document.querySelectorAll('*')) {
if (el.getBoundingClientRect().right > limit) {
console.log(el, Math.round(el.getBoundingClientRect().right));
}
}The trail ended at a single footer column. In the computed styles panel: margin-left: 151px. On a 360px screen. The column itself had a percentage width, but its left margin was hard pixels, and 151px is nearly half the width of a phone.
The root cause
I opened the element's settings in Elementor and found the inheritance waiting for me: a column margin set years ago, stored in the element data roughly like this:
{
"elType": "column",
"settings": {
"_column_size": 25,
"margin": {
"unit": "px",
"top": "0",
"right": "0",
"bottom": "0",
"left": "151",
"isLinked": false
}
}
}Someone, once upon a time, had nudged that column into position with a margin instead of with layout. On desktop it looked correct, so nobody ever questioned it. The problem: pixel margins are not responsive. Elementor silently cascades desktop values down to tablet and mobile unless an explicit per-breakpoint override exists. No warning, no yellow triangle. The exact same 151px left margin applies on a 360px phone.
Then a second factor made it worse: the section used content_width: boxed and the columns had percentage widths. Percentages are computed from the container, but pixel margins get added on top. The columns' total width, percent plus fixed margin, exceeded 100vw on small screens. Desktop had room to absorb those 151px; a 360px screen did not.
So this was not one bug but a stack of legacy decisions: positioning by margin, desktop values cascading without overrides, and a boxed width that made the math blow up precisely on the narrowest screens.
The fix
The first thing I shipped was a temporary CSS guard, so visitors would stop seeing a broken footer while I cleaned up the settings:
@media (max-width: 767px) {
.footer-column {
margin-left: 0 !important;
width: 100% !important;
}
}Then the real fix, inside the Elementor settings:
One, audit every footer column for pixel margins. DevTools works, so does reading the element data directly. Any px margin on a column is a suspect.
Two, remove the positional margins. The column that had been shoved 151px by margin went back into place using actual layout: column gap and justify at the section level. Where a margin genuinely served the design, I set it per breakpoint, with mobile at zero.
Three, force the columns to stack at 100% width on mobile, and make the boxed content width behave: boxed_width set to 100% on mobile, or switch the section to full width with padding. On a 360px screen there is no world in which four columns should stand side by side.
Once the settings were clean, I pulled the CSS guard out. A guard left in permanently just becomes the next legacy layer for whoever inherits the site after me.
Verification
I rechecked in DevTools device mode with rulers on, then compared scrollWidth against clientWidth again: identical now. But I did not stop there. Device mode is not always honest about scrollbars and momentum scrolling, so the final verification always happens on a real phone: open the page, try to drag it sideways. A healthy page does not budge.
The takeaway
Pixel margins used for positioning are positional hacks, and positional hacks break the moment the viewport changes. Desktop values in Elementor cascade down to tablet and mobile silently unless you override them per breakpoint, so every px number you type on desktop is a promise you are also making to a 360px screen. Horizontal overflow debugging is always the same hunt: find the element whose width plus margin exceeds the viewport, and the scrollWidth walk is your best friend. And above all: lay out with gaps, not margins. Gaps belong to the container and obey the layout; margins belong to the element and carry their old grudges down to every breakpoint.
