Test my website on different devices: what breaks

Most sites are built and checked with a mouse in a wide window. A phone changes three things at once: the width of the screen, the input (a finger, no hover, and an on-screen keyboard that covers part of the page), and the browser, which may be Safari on an iPhone, Chrome on Android, or a social app's built-in browser. Width breaks the layout. Input breaks menus, small buttons and forms. The browser breaks page height and zoom. A laptop check with a mouse only exercises the first, so the other two stay hidden until a visitor runs into them.

• Tiny text that needs a pinch to read on a phone means the page is not set up for phone widths.
• Scroll sideways on the phone. Anything that moves the page left or right is wider than the screen.
• Tap every menu item with a thumb. Hover-only items may do nothing, or open and then navigate on the next tap.
• Tap each form field and check that the button you need stays visible above the on-screen keyboard.
• Note whether a cookie banner or chat bubble covers the main button on the first screen.

A phone visitor first sees the top of the page in a narrow column, with the browser's toolbars using part of the screen. A section sized to the full screen height can end under that toolbar, so the main button sits where a thumb cannot reach it. Next is the menu. A menu that opens only on hover behaves unpredictably on a phone: the visitor taps and gets nothing, or taps again and lands somewhere unexpected. Then the form. iOS Safari zooms in when a visitor taps a field with text under 16 pixels, and the page can stay zoomed, pushing the submit button off the screen.

Wide things come next. A table, code sample or pricing grid wider than the phone pushes the whole page sideways, and the right edge is cut off. Overlays come last. A cookie banner or a chat bubble can cover most of a small screen, and the sign up button under it is never tapped. A visitor who meets one of these does not write a bug report. They close the tab, and the page still looks fine to you on your laptop.

Most breaks come from one of three causes. Width means the layout does not fit the screen, so boxes overlap or the page scrolls sideways. Input means the page works with a mouse but not a finger, or the on-screen keyboard hides a field and the button below it. Browser means the page behaves differently in one phone browser than in another. Each cause needs a different fix.

Find the cause from your laptop first. Drag the window to phone width, or open the browser's phone view. If the page scrolls sideways or boxes overlap there, the cause is width. If the layout is fine at that width but a control fails under a finger on a real phone, the cause is input: the mouse hid it, because hover works with a mouse and not a finger. If the phone's normal browser and the browser inside a social app disagree, the cause is the browser.

Your phone is never a stranger's phone. You are logged in, the cookie banner was dismissed long ago, and you know where the menu is. A first-time visitor from a search or a social post has none of that. Open the page in a private window on the phone to see the first screen, the banner and the empty form the way a new visitor does. Some social apps open links in their own built-in browser, which can behave differently from Safari or Chrome, so open the link the way a visitor would.

Write the task the way a visitor would be told it, such as finding the price and starting a free trial, and run it in laptop and phone browsers. Compare the step where each one stopped. The report gives the step, a screenshot and any JavaScript error or slow request on it, so a menu that does nothing shows up as a stop with a picture. Fix the step, then run the same task again on both devices to see who gets further.

Test a signup flow

Every layout fix or new banner can break a phone that worked last week. Run the same task on a laptop and a phone after every change, and again when a preview deploy goes up. A GitHub Action can run visitors on each Vercel, Netlify or Cloudflare preview and keep one comment on the pull request. Protected previews need paid credits and a site password or a bypass secret.