Responsive design and mobile layout testing

Most layouts are designed on a wide screen and break quietly on a phone. This page explains which widths to test, the layout bugs that come up again and again, and a task your AI beta tester can run at phone and tablet sizes.

Who it’s for

  • Teams whose visitors arrive mostly from phones
  • Designers and front-end developers shipping new layouts
  • Marketers launching landing pages and campaigns
  • Store owners whose checkout must work on mobile

Updated 2026-10-19.

What responsive design testing checks

Responsive design testing checks that your layout adapts cleanly to every screen size your visitors use, from a small phone to a wide desktop monitor. It is not about whether the site looks identical everywhere; it is about whether every page stays readable and every flow stays usable as the width changes.

Layout bugs are easy to miss because the team usually works on large screens. A beta test that deliberately visits the narrow and in-between widths finds the overflowing tables, hidden buttons and covered inputs before your mobile visitors do.

Which screen widths to test

You do not need every device. Test a few widths that cover the breakpoints where layouts change:

  • Small phone: around 360–375px wide
  • Large phone: around 390–430px
  • Tablet portrait: around 768–820px
  • Small laptop: around 1280px
  • Large desktop: 1440px and up

Also resize slowly between breakpoints: many bugs live in the in-between widths nobody designed for.

How to run a responsive design test

  1. List the page templates: home, pricing, a content page, a form, the app dashboard and any page with a table or wide media.
  2. Pick your flows: the two or three journeys that matter most, such as signup, the core task and checkout.
  3. Start at the smallest width and go through each template, scrolling to the bottom.
  4. Interact, don't just look: open the menu, fill in forms, open modals, use filters and tabs.
  5. Step up through the breakpoints and slowly drag the width between them.
  6. Rotate and zoom: landscape on a phone-sized view and 200% zoom on desktop.
  7. Add a real-phone pass for your most important flow.
  8. Report each issue with the width, page, screenshot and expected behavior.

Responsive design checklist

Layout and content

  • No horizontal scrolling: one wide element (a table, an image, a long word or URL, a fixed-width embed) can make the whole page scroll sideways.
  • Headings wrap instead of being cut off, and button text stays inside the button.
  • Images keep their proportions, crop sensibly and are not heavier than needed on mobile.
  • Tables scroll inside a container or switch to a stacked layout instead of breaking the page.
  • Columns stack in a logical reading order.

Navigation and overlays

  • The mobile menu opens, closes and scrolls when it has many items.
  • Sticky headers, cookie banners and chat widgets do not cover content or the main button.
  • Modals taller than the screen can be scrolled to the close button.
  • Hover-only menus and tooltips have a tap or click equivalent.

Forms and touch

  • Inputs are wide enough to see what you typed.
  • The on-screen keyboard does not cover the submit button or the active field.
  • Email, phone and number fields bring up the right keyboard type.
  • Tap targets are large enough and not packed together.

Orientation and zoom

Rotate to landscape on a phone: fixed headers can take half the screen. Zoom to 200% on desktop: content should reflow without overlapping, which is also a WCAG requirement.

Viewport testing vs real phones

Resizing a desktop browser to phone width catches most layout bugs and is fast. Real phones add touch behavior, the on-screen keyboard, browser toolbars that change the visible height, and platform fonts. For a site, start with viewport testing and add a real-device pass for your most important flows; for a mobile app, test on the phone itself.

Example bug report

Title: Pricing comparison table forces horizontal scroll on phones
Environment: Safari on iPhone-width viewport, 390px wide, portrait
Page: /pricing
Steps to reproduce:
1. Open /pricing at 390px wide
2. Scroll to "Compare plans"
3. Try to scroll the page vertically past the table
Expected: the table scrolls inside its own container, or stacks per plan;
          the rest of the page stays 390px wide
Actual: the whole page is about 720px wide; the header and footer shift
        sideways and the "Start free" button is off screen
Severity: High (main conversion page is hard to use on mobile)
Evidence: annotated screenshot with the overflowing table marked

Common mistakes

  • Testing only the exact widths in the design file and skipping the in-between ones.
  • Looking at static pages without opening menus, modals and forms.
  • Forgetting long real content: long names, translated text, big numbers and URLs.
  • Assuming a responsive framework handles everything, then adding one fixed-width embed.
  • Reporting "mobile looks off" without the width, page or a screenshot.

What to fix first

  1. Blocked flows: buttons that cannot be reached, forms that cannot be submitted, menus that do not open.
  2. Horizontal scrolling and covered content on high-traffic pages.
  3. Readability: cut-off text, tiny tap targets, overlapping elements.
  4. Visual polish: spacing, image cropping and alignment that do not stop anyone.

How to report a layout bug

Always include the width (or device), the page URL, a screenshot with the broken area marked, and what you expected. "The header overlaps the title at 390px" is fixable in minutes; "mobile looks off" is not.

Doing it manually vs with an AI beta tester

Manually dragging the browser window works, but checking every template at five widths on every release is slow, and it is the first thing skipped when a deadline is close.

An AI beta tester like betatest.ing visits your pages at several viewport widths in a real browser, interacts with menus, forms and modals, and files each layout bug with the width, steps, severity and an annotated screenshot or recording. It can also test on Android emulators and real iOS devices for apps, and you can schedule the run after each deploy so layout regressions show up quickly.

What it does not replace: judgment about whether a layout feels right to your audience, and real-world conditions on people's own phones, such as slow networks or unusual system settings. Treat it as a reliable regression net, and keep an eye on real-user feedback.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Check the main pages of [SITE URL] at mobile (390px), small phone (360px) and tablet (820px) widths using the viewport action, plus a slow resize between them. Pages to cover: [PAGES TO CHECK]. On each width look for horizontal scrolling, overlapping or cut-off text, images that overflow or stretch, tap targets that are too small or too close, the mobile menu (open, close, scroll), sticky headers, cookie banners or chat widgets covering content or buttons, forms and the keyboard type, modals taller than the screen, tables that break the layout, and anything that only works on hover. Also check landscape on the phone width. Annotate a screenshot for each issue and say which width it happens at. Switch back to desktop at the end. Report what works and what breaks per page and width, with the 5 most important fixes first.

Fill in your details

Here, or later in the chat with your tester.

  • [SITE URL] Your site or app, e.g. https://example.com
  • [PAGES TO CHECK] e.g. "home, pricing, signup and checkout" or "every page in the main menu"

What the AI beta tester checks

  • Horizontal scrolling at each width
  • Overlapping, cut-off or non-wrapping text
  • Tap target size and spacing
  • Mobile menu: open, close and scroll
  • Sticky headers, banners and widgets covering content
  • Images, tables and embeds that overflow
  • Forms, keyboards and modals on small screens
  • Hover-only interactions and landscape layout

What you get

  • Annotated screenshots for each layout bug, with the width noted
  • A per-page, per-width table of what works and what breaks
  • Bugs with steps to reproduce
  • The 5 most important fixes, ranked

How to run it with betatest.ing

  1. Add your site as a project
  2. Paste the task and list the pages that matter most
  3. Send it; the tester switches viewports and checks each page
  4. Fix the issues and schedule the check after each design change

Tips

  • Test the pages that make money first: home, pricing, signup, checkout
  • Include your longest real content (long product names, long translations) to catch overflow
  • Close the cookie banner last: check that it does not cover the main button first
  • Add a real-phone pass for the checkout or signup flow

Responsive design testing: FAQ

Is resizing the browser enough for mobile testing?

For layout bugs, usually yes. Touch behavior, the on-screen keyboard, toolbars and platform fonts need a real phone, so test your critical flows on a device too.

Which devices should I test?

Test widths rather than device names: a small phone, a large phone, a tablet and a laptop cover the breakpoints that matter. Check your analytics for the sizes your visitors actually use.

Does the tester check landscape mode?

Yes, if you ask. The task above includes a landscape check at phone width.

What is the most common mobile bug?

Horizontal scrolling caused by one element that is wider than the screen, such as a table, a long URL, a fixed-width image or an embed.

Do I need to test tablets separately?

Yes, at least briefly. Tablets sit between phone and desktop breakpoints, so they often get a stretched phone layout or a cramped desktop one, and touch replaces the mouse. A quick pass in portrait and landscape on your main pages usually finds the problems.

How do I fix horizontal scrolling on mobile?

Find the one element that is wider than the screen: usually a table, an image, an embed with a fixed width or a long unbroken word or URL. Let tables scroll inside their own container, give media a maximum width of 100%, and allow long words to wrap. Then re-test at the narrowest width.

How often should I run responsive design tests?

Run them before launch and after any change to layout, navigation or shared components. Scheduling a quick check after each release catches the common case where one new element breaks the mobile layout of a page nobody looked at.

Related beta testing guides

  • Cross-device testing — Your product will be used on phones, tablets and laptops of every size, in different browsers. This page helps you choose a sensible device mix, lists what typically breaks between devices, and gives you a task for your AI beta tester.
  • Accessibility testing — Accessibility problems lock real people out of your product, and many of them are easy to find and fix. This page covers the WCAG checks a careful browser pass can do, what it cannot replace, and a ready task for your AI beta tester.
  • Mobile app beta testing — Mobile apps reach testers through store testing tracks, run on hardware you do not control, and get interrupted constantly. This guide covers how to distribute a mobile beta, what to test that is specific to phones, and how an AI beta tester fits alongside your human testers.
  • Landing page testing — A landing page has one job: make a visitor understand the offer and take the next step. Testing it means checking both that it works and that it is clear. This page covers what to check on a landing page before you send traffic to it, and a task your AI beta tester can run.
  • Website beta testing — A website beta test is a run-through of your site by someone who has never seen it, before real visitors do. This guide covers what breaks most often on marketing and content sites, how to set up the test, and a ready-to-run task your AI beta tester can start on right now.
  • Free tool: Free website test — Enter a URL, get an instant report: SEO basics, mobile, security headers, broken links and a score.

More in by test type