Website problems
Horizontal scrolling on mobile
Horizontal scrolling on a phone happens when some element on the page is wider than the viewport. The browser makes the entire page scrollable sideways to accommodate it, so every other element shifts and the layout appears broken. It is almost always one element — a fixed-width table, an oversized image, a long unbroken string, a negative margin — and the whole page pays for it. Finding which element is the entire diagnostic problem.
The six usual culprits
A fixed width in pixels on a container: `width: 1200px` on an element inside a responsive layout. The most direct cause and the easiest to find.
An image with no `max-width: 100%`. A 2000-pixel image in a 390-pixel viewport overflows by 1610 pixels unless something constrains it.
Tables. HTML tables size to their content and do not wrap, so a table with six columns of data is as wide as its content requires, regardless of the screen.
Long unbroken strings: a URL, an email address, an API key in a code sample, a hash. There is no break opportunity, so the line extends past the edge.
Elements positioned or transformed outside the container — a decorative shape with `left: -50px`, or an absolutely positioned element whose parent is not `position: relative`.
Embedded third-party content: an iframe with a fixed width, a map, a video player, a payment widget, each sized for desktop.
Why one element affects the whole page
The document's scrollable width is the width of its widest content. One element extending to 1200 pixels makes the document 1200 pixels wide.
So every other element — the header, the footer, the text — now sits in a viewport that scrolls, and moving sideways to read one line shifts all of it.
This is why the symptom is reported as 'the mobile layout is broken' rather than 'this table is too wide'. The visible damage is everywhere and the cause is in one place.
It also explains why the problem appears and disappears between pages: the element is on some templates and not others.
How to find the offending element
In the console, on a phone-width viewport: `[...document.querySelectorAll('*')].filter(el => el.getBoundingClientRect().right > document.documentElement.clientWidth)`. That returns the elements extending past the right edge, and the first one in document order is usually the cause.
Alternatively, add `* { outline: 1px solid red }` temporarily and scroll sideways. The element that extends is visible immediately.
Check the computed width of the `<body>` and `<html>` elements: `document.documentElement.scrollWidth` against `document.documentElement.clientWidth`. A difference is the overflow, in pixels.
Do it at 320 pixels wide as well as at a common phone width. Some overflow appears only on the narrowest screens still in use.
How to fix each cause
Fixed widths: replace with `max-width` plus a percentage or `100%`. An element that may be 1200 pixels wide and must not exceed the viewport is `max-width: 1200px; width: 100%`.
Images: `img { max-width: 100%; height: auto }` as a baseline rule. This single rule removes the most common cause site-wide.
Tables: wrap in a container with `overflow-x: auto`, so the table scrolls within its own box instead of making the page scroll. This is the one case where scoped horizontal scrolling is the right answer.
Long strings: `overflow-wrap: anywhere` on the containing element, which allows a break where none would otherwise exist.
Positioned elements: give them `max-width` constraints, or clip them with `overflow: hidden` on their own container rather than on the page.
Third-party embeds: constrain the wrapper and let the embed scale, using an aspect-ratio box for video and maps.
Why overflow:hidden on the body is not the fix
`body { overflow-x: hidden }` stops the page scrolling sideways. It does not stop the element being too wide — it hides the part that overflows.
So the content is still there and now unreachable. A table whose last two columns are clipped is worse than one that scrolls, because nothing indicates the columns exist.
It also breaks `position: sticky` in some browsers, which produces a second bug that nobody connects to the first.
It is a legitimate defensive rule on top of a page with no overflow, as a guard. It is not a remedy for a page that has some.
How VeriFixScan detects it
`mobile.horizontal_scrolling` renders each crawled page at a mobile viewport width and reports the pages whose content extends beyond it, with the measured overflow.
`mobile.content_width` reports the relationship between the content width and the viewport width, which distinguishes a page overflowing by a few pixels from one laid out for a desktop.
`mobile.viewport` covers the prior question of whether the page declares a viewport at all — a page without one is scaled rather than overflowing, which is a different problem with a similar description.
`mobile.responsive_images` reports the images that are a common contributor.
Frequently asked questions
- How do I find which element is too wide?
- In the console at a phone width, filter every element by whether its bounding rectangle extends past document.documentElement.clientWidth. The first match in document order is usually the cause.
- Is overflow-x: hidden a valid fix?
- No. It hides the overflowing content rather than fitting it, so the clipped part becomes unreachable, and it can break position: sticky. Use it as a guard on a page that already fits, not as a remedy.
- Why does only one page scroll sideways?
- Because the offending element is on that template and not the others — typically a wide table, an embed, or an image without a max-width constraint.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website