Horizontal Scroll on Mobile: How to Find and Fix It

When this check fires, our crawler loaded your page at a typical mobile width and found that the document is wider than the viewport. In plain terms: the page does not fit on the screen. A visitor on a phone has to swipe sideways just to read a paragraph, and half the layout drifts off into dead space. It looks broken, because it is.

What this check flags

The flag is simple under the hood. We compare the rendered width of your content against the width of the device viewport. If the content is wider, the browser adds a horizontal scrollbar and the page can be dragged sideways. Google treats this as a mobile usability problem because it directly hurts how people read and tap on small screens. One element almost always causes it, and the rest of your layout just gets pushed along for the ride.

The usual culprits

Horizontal overflow comes from a short list of repeat offenders. Knowing them shortens the hunt:

Fixed pixel widths. An element hardcoded to something like width:400px will happily blow past a 360px phone screen. It looked fine on your desktop and never adapted.

Unconstrained images and embeds. A large image, iframe, or video with no responsive rule keeps its native width and shoves the page open.

Wide tables. Data tables with many columns do not wrap. They simply stretch until they fit, even if that means running off the screen.

Negative margins and oversized padding. A negative left or right margin, or padding added on top of a full-width element, can push content past the viewport edge.

100vw plus a scrollbar. The vw unit is not scrollbar aware. If the page has a vertical scrollbar, a width:100vw element is slightly wider than the visible area, and you get a thin, maddening sideways scroll. Percentages do not include the scrollbar, so they fit.

Overflowing pre and code blocks. A long unbroken line of code or a wide preformatted block will not wrap on its own and drags the layout wide.

How to diagnose it

Before you fix anything, find the actual offender. Guessing is how people end up plastering band-aids over a problem they never located. Hunting down the one rogue element that is quietly shoving your whole damn page sideways is the entire job, and it takes about two minutes with the right trick.

Open your page on a phone or in your browser's device emulation mode. Then drop this into the DevTools console to list every element wider than the document:

var docWidth = document.documentElement.offsetWidth;
[].forEach.call(document.querySelectorAll('*'), function (el) {
  if (el.offsetWidth > docWidth) {
    console.log(el);
  }
});

Whatever logs is your suspect. If you prefer a visual approach, temporarily outline everything and look for the box that pokes past the edge:

* { outline: 1px solid red; }

Select the flagged element in the Elements panel and check its computed width, margins, and padding. Nine times out of ten you will spot a fixed pixel value, a 100vw, or a stray negative margin.

How to fix it

Once you know the offender, the fix is targeted. Start with images and media, which should never exceed their container:

img, video, iframe, svg {
  max-width: 100%;
  height: auto;
}

Make sure padding and borders are counted inside element widths rather than added on top, which prevents a full-width box from overflowing:

*, *::before, *::after {
  box-sizing: border-box;
}

For wide tables, do not crush the table. Let it scroll inside its own wrapper so the rest of the page stays put:

.table-wrap {
  overflow-x: auto;
  -webkit-overflow-scrolling: touch;
}
/* <div class="table-wrap"><table>...</table></div> */

Apply that same overflow-x:auto pattern to code blocks so a long line scrolls within the block instead of the page. Replace any width:100vw with width:100%, and swap fixed pixel widths for max-width with a percentage or a flexible unit so elements shrink on small screens. The principle throughout: put the scroll on the specific container that needs it, never on the whole document.

Common mistakes

The biggest one is reaching for overflow:hidden on the body or html as a quick patch. It hides the scrollbar, so the audit may go quiet, but the overflowing element is still there, clipped off screen where nobody can reach it, and you can break sticky positioning and anchor scrolling in the process. It is a cover-up, not a repair. Find the real element and constrain it instead.

The second mistake is fixing one offender and stopping. Run the console snippet again after each change, because a page often has more than one wide element and they reveal themselves one at a time. The third is testing only on desktop emulation. Confirm on a real phone, where touch scrolling and real scrollbar behavior tell the truth.

FAQ