What actually breaks on a phone

A desktop browser’s mobile simulator resizes the viewport; it does not reproduce a real phone’s touch behaviour, on-screen keyboard, dynamic address bar, or genuine rendering engine on some platforms — which is why a site that “passes” the simulator can still fail in specific, repeatable ways for mobile users on an actual smartphone. Good mobile design accounts for these failures deliberately rather than assuming a responsive layout alone is enough.

The failures that show up on real phones and not in a simulator

On-screen keyboard covering the active form field. When a mobile keyboard opens, it takes up close to half the screen. A form field positioned near the bottom of the visible area, or a submit button that was visible before the keyboard opened, can be pushed off-screen entirely, and a simulator running on a desktop monitor with no keyboard to trigger has no way to reveal this.

The dynamic browser address bar changing the available viewport. Several mobile browsers expand and collapse the address bar as a user scrolls, which changes the actual visible height of the page in real time. A layout built assuming a single fixed viewport height (common with 100vh CSS on a full-screen hero section) can show a gap or an overlap as the address bar animates — a desktop simulator with a static toolbar never demonstrates this.

Hover-dependent interactions with no touch equivalent. A menu or a tooltip that only appears “on hover” has no direct equivalent on a touchscreen, where there is no cursor to hover. A simulator using a mouse pointer to represent touch input does not reveal that the real interaction has no way to trigger at all on a genuine touch device.

Tap targets that are technically large enough in CSS but visually crowded. Two links or buttons that meet a minimum size requirement individually can still sit close enough together that a real thumb — wider and less precise than a simulator’s mouse cursor click point — frequently taps the wrong one. This is covered in more depth on touch targets and thumb reach on a small screen.

Notches, camera cutouts and safe-area insets. Content placed at the very edge of the screen, particularly a fixed header or footer, can be obscured by a device’s notch or rounded corners on some phones — a failure with no equivalent on a rectangular desktop simulator viewport at all.

Genuine rendering differences between browser engines. Not every mobile browser uses the identical rendering engine, and some CSS or JavaScript behaviour genuinely differs between them — covered further on browser and device compatibility.

Autofill and password-manager overlays covering nearby controls. A phone’s built-in autofill suggestion bar, appearing just above the on-screen keyboard when a form field is focused, can sit directly over a button or another field that was visible a moment earlier — a failure that, like the keyboard-covering issue above, has no equivalent on a desktop simulator with no on-device autofill bar to trigger.

Disabling pinch-to-zoom, which is both a usability and an accessibility failure. Some sites set a viewport configuration that prevents pinch-zooming, often to stop a double-tap accidentally zooming an already-responsive layout — but doing this also prevents a low-vision visitor from zooming in on genuinely small text, which runs directly against WCAG’s requirement that text remain resizable. A simulator rarely surfaces this because it is not usually tested by someone who actually needs to zoom to read the page.

Pull-to-refresh gestures conflicting with custom scrolling components. Many mobile browsers treat an upward pull at the very top of a page as a refresh gesture, which can interfere with a custom-built carousel, image gallery or scrollable panel positioned at the top of the page if it was not built with this device-level gesture in mind — a conflict that only appears when actually swiping on a real touchscreen, not when dragging with a simulator’s mouse pointer.

Interstitials and pop-ups that block the whole screen on a small device. A newsletter sign-up or a cookie notice that comfortably occupies a corner of a desktop screen can cover almost the entire visible area on a small phone screen, and a close button placed where a desktop pointer would easily reach it can sit outside a thumb’s comfortable range on some mobile devices. A simulator’s larger default viewport frequently understates how intrusive the same interstitial actually feels on a genuinely small screen.

A short, checkable list

Failure	How to check it on a real device
Keyboard covers the active field	Tap into every form field near the bottom of a page and confirm it stays visible
Layout shifts as the address bar collapses	Scroll slowly down and back up on a long page and watch for content jumping
Hover-only interactions	Try to trigger every menu and tooltip by tapping, not hovering
Crowded tap targets	Attempt to tap each link or button with a thumb, not a fingertip stylus-precision tap
Content obscured near screen edges	Check fixed headers and footers on a device with a notch or rounded screen corners

Why a simulator is still worth using, just not as the final check

A browser’s built-in device simulator is a fast, free first pass that catches obvious layout breaks — content overflowing horizontally, text too small to read, images not scaling — and is worth using early and often during a build. What it cannot do is replace the final check on an actual device before anything goes live, covered in full on testing your website on real devices.

What to do next

Work through the checklist above on a real phone against a live or staging version of the site. For the systematic version of this check across multiple real devices, testing your website on real devices is the next page. If several of these failures turn up, web development services covers what fixing them typically involves as part of a build or a retainer.