Mobile layout issues to fix before a website launch

Short answer: the mobile problems that most often slip through before launch are pages that scroll sideways (something is wider than the screen), a missing viewport tag, text and buttons that are too small to read or tap, images and embeds that don’t scale, and sticky headers, menus or banners that cover content. Check every page at a narrow phone width (about 390px), find the element that breaks the layout, fix it with responsive CSS rather than hiding it, then confirm on a real phone.

This guide is for small agencies and freelancers launching marketing and brochure sites. Items marked “Proofday checks this” are covered by Proofday’s automated check; everything else needs a person and a phone.

1. The page scrolls sideways Proofday checks this

Sideways (horizontal) scrolling is the most common mobile layout bug, and the easiest to miss on a desktop browser. It means at least one element is wider than the screen. Typical causes:

• Fixed widths in CSS, such as width: 1200px or a min-width on a section.
• Images, videos, map or booking iframes without max-width: 100%.
• Long unbroken text: URLs, email addresses, product codes, long compound words.
• Wide tables or pricing grids that don’t stack.
• Elements sized with 100vw, negative margins, or off-screen animation start positions.

How to find it: open the page in Chrome DevTools device mode at 390px wide, then paste this in the console. It lists every element whose right edge goes past the screen:

const w = document.documentElement.clientWidth;
[...document.querySelectorAll('body *')]
  .filter(el => el.getBoundingClientRect().right > w + 1)
  .forEach(el => console.log(el, Math.round(el.getBoundingClientRect().right) + 'px'));

Fix the outermost element in the list first; the others are often its children. Common fixes:

img, video, iframe, svg { max-width: 100%; height: auto; }
iframe { aspect-ratio: 16 / 9; width: 100%; }
p, li, a, td { overflow-wrap: anywhere; }
.table-wrap { overflow-x: auto; }   /* wrap wide tables in this */

Avoid putting overflow-x: hidden on body as the fix. It hides the symptom, can cut off real content, and can stop position: sticky headers from working.

2. The viewport tag is missing Proofday checks this

Without <meta name="viewport" content="width=device-width, initial-scale=1"> in the <head>, phones render a shrunken desktop page. Most builders add it, but it goes missing on hand-coded templates, landing-page tools and old themes. While you’re there, don’t add maximum-scale=1 or user-scalable=no: blocking pinch-zoom makes the site harder to use for people with low vision.

3. Text and tap targets are too small

• Body text is comfortable to read without zooming; around 16px is a common baseline.
• Form inputs use at least 16px text, or iPhone Safari zooms in when a visitor taps the field.
• Buttons and links have enough room to tap. WCAG 2.2 sets a minimum target size of 24×24 CSS pixels (or enough spacing around smaller targets); Apple’s guidelines recommend about 44×44 points.
• Footer links, social icons and inline links in dense text aren’t packed so tightly that a thumb hits the wrong one.

4. Images, video and embeds don’t scale

• Hero images are cropped sensibly on a tall, narrow screen (faces and text aren’t cut off).
• Text baked into images is still readable at phone width, or replaced with real text.
• YouTube, Vimeo, maps and booking widgets keep their shape (use aspect-ratio instead of fixed heights).
• Every image actually loads, including lazy-loaded ones further down the page. Proofday checks this

5. Headers, menus and banners cover the page

• The sticky header doesn’t take up a large share of a phone screen.
• The menu button opens and closes the menu, a long menu can scroll, and the page behind it doesn’t scroll instead.
• Cookie banners, chat widgets and popups don’t cover the main button or the form submit button, and they can be closed.
• Full-height sections using 100vh don’t hide content behind the iPhone browser bar; 100svh or 100dvh usually behaves better.

6. Forms are awkward on a phone

• Fields use the right input types (type="email", type="tel") so the matching keyboard appears.
• Labels stay visible while typing; placeholder text isn’t the only label.
• Error messages appear next to the field, not off-screen at the top.
• The form actually submits and the message arrives. Test this by hand.

7. Widths in between break

Many layouts look fine at 390px and 1366px and fall apart at 768px or 1024px, where columns squeeze before the breakpoint switches. Drag the browser width slowly from narrow to wide and watch for overlapping text, squashed cards and orphaned buttons. Check landscape on a phone too.

8. Confirm on a real phone

Device emulation in Chrome is good for layout, but it isn’t Safari on an iPhone. Before launch, open the key pages on at least one real iPhone and one Android phone: home, a service or product page, contact, and anything with a form or booking widget.

How to write a mobile layout ticket

Mobile bugs are easy to describe badly (“mobile looks off”). A ticket the developer can act on names the page, the width and the element:

• Title: Services page: pricing table makes page scroll sideways on mobile
• Where: /services, 390px wide (iPhone 12–15 size), Chrome device mode
• Steps: open the page, scroll to “Packages”, swipe left
• Expected: page fits the screen; table stacks or scrolls inside its own box
• Actual: whole page is 612px wide; the table has a fixed width
• Evidence: screenshot with the table highlighted
• Suggested fix: wrap the table in a container with overflow-x: auto, or stack rows below 600px

FAQ

Why does my website scroll sideways on mobile?

Something on the page is wider than the phone screen. Common causes are fixed pixel widths, images, videos or iframes without max-width:100%, long unbroken URLs or email addresses, wide tables, and elements sized with 100vw or pushed off-screen by negative margins or animations.

How do I find the element that causes horizontal scrolling?

Open the page in Chrome DevTools device mode at about 390px wide and paste a short console snippet that lists every element whose right edge is past the screen width. Fix the outermost element in that list first, then reload and check again.

Is overflow-x: hidden on the body a good fix?

Usually not as the first fix. It hides the symptom, can cut off content, and can stop position: sticky from working. Find and fix the element that is too wide; use overflow clipping only on a specific container that is meant to clip.

What screen width should I test before launch?

Test a narrow phone width (about 360 to 390px), a tablet width (about 768px), and a small laptop (about 1280 to 1366px), plus at least one real phone. Also drag the browser width slowly between breakpoints to catch layouts that break in between.

Does Proofday test on real phones?

No. Proofday loads pages in Chromium with a 390×844 mobile viewport and a 1366×768 desktop viewport. Safari, Firefox and real devices are not tested and are marked that way in the report.

Updated 2026-10-19 by Proofday. Related: 36-item website launch checklist · Webflow QA before launch · Framer launch checklist · Client handoff QA · Proofday vs free tools