How to test a website on mobile
Test on mobile in two passes. First use your browser's device mode to sweep through narrow widths quickly and catch layout faults. Then use a real phone, on mobile data, to catch what emulation misses: touch, the on-screen keyboard, the browser's own bars and real loading speed. Each pass finds problems the other doesn't.
Pass one: browser device mode
- Open the page in Chrome or Edge, open DevTools (F12, or Cmd+Option+I on a Mac) and turn on the device toolbar. Firefox and Safari have equivalent responsive design modes.
- Choose Responsive rather than a named device, and set the width to 320 pixels: about the narrowest phone in common use. Scroll the whole page.
- Drag the width slowly up to around 430 pixels, then to tablet widths. Watch for the point where something jumps, overlaps or wraps badly.
- Turn on touch simulation, if your tool offers it, so hover-only effects show up as the problems they are on a phone.
- Throttle the network to a slow mobile profile and reload, to see what the page looks like while images are still arriving.
Chrome's device mode documentation is clear that it's an approximation: it emulates the viewport and touch, not the phone's actual browser engine or performance.
Pass two: a real phone
- Open the address on your own phone, on mobile data rather than Wi-Fi.
- Hold it in one hand and use your thumb. Can you reach and hit every button without zooming?
- Fill in every form. Check the right keyboard appears: numbers for phone fields, the @ key for email.
- Rotate to landscape and back.
- Scroll to the bottom with the browser's address bar collapsing and expanding, and check nothing important hides behind it.
- If you can, borrow a phone of the other platform: iPhone if you have Android, or the reverse. Safari on iOS and Chrome on Android render some things differently.
The faults that show up most
| Fault | How to spot it | Usual cause |
|---|---|---|
| Sideways scrolling | The page wobbles left and right, or a gap appears on the right | An image, table or long word wider than the screen |
| Tiny tap targets | You hit the wrong link, or have to zoom to tap | Links packed together; WCAG 2.2 sets a 24 by 24 pixel minimum target, and larger is easier |
| Text too small | You squint or zoom to read body text | Body text under 16 pixels, or a missing viewport meta tag |
| Hero taller than the screen | The first screen shows only a picture and no clue what to do | A hero forced to full screen height |
| Hidden content | A fixed header or cookie bar covers text or buttons | Fixed elements with no space reserved |
| Hover-only information | Details that appear only on hover never appear | Effects designed for a mouse |
| Zoom blocked | Pinch-to-zoom doesn't work | maximum-scale=1 or user-scalable=no in the viewport tag |
Two accessibility criteria are worth knowing by name. Target size (minimum) covers how big tap targets should be, and reflow requires content to work at a width of 320 CSS pixels without scrolling in two directions.
A quick check for sideways scrolling
If the page scrolls sideways and you can't see why, open the DevTools console and paste [...document.querySelectorAll('*')].filter(e => e.scrollWidth > document.documentElement.clientWidth). It lists elements wider than the viewport; the deepest one in the list is usually the culprit.
How Anticode helps
Anticode's design gate won't publish a page without a phone viewport, and the Critic checks for habits that hurt small screens, such as body text under 16 pixels and a hero forced to full screen height. For app builds, when Cloudflare Browser Rendering is available, the build opens the new app in headless Chrome at a phone width and a laptop width, takes screenshots and clicks through it, and the Critic fixes what it finds before you see it.
Those checks narrow the problems; they don't replace your thumb on a real phone. Run pass two before every launch. The website launch checklist puts it in order with the other pre-launch checks.
Limits
Automated screenshots catch layout breaks, not confusing wording or a booking flow that's tiring on a small screen. Watch one real person, ideally someone who hasn't seen the site, try to do the main task on their own phone. That five minutes usually finds the problem everyone else had stopped noticing. For the accessibility side, see accessibility problems in AI-generated websites.
Questions people ask
Can I test on an iPhone without owning one?
Device mode can show iPhone widths, but not Safari's actual rendering. Borrow a phone, or use a cloud device-testing service for a real Safari session.
Which widths should I test?
Sweep from 320 pixels upwards rather than picking devices. Problems appear at breakpoints between devices, not only at their exact sizes.
Why does my site look fine in device mode but wrong on my phone?
Usually the browser's own bars, the on-screen keyboard, font rendering or a slow connection. Those are exactly what the real-phone pass is for.