Why Chrome’s iPhone Mode Looks Different From Safari on a Real iPhone

TLDR

Selecting an iPhone preset in Chrome does not launch Safari.
Use Device Mode for viewport, pixel-density and input-condition checks.
Inspect an actual iPhone page through Safari’s Develop menu on a connected Mac.

The iPhone preset still runs your page in Chrome

A successful Device Mode preview does not confirm Safari compatibility. Chrome’s documentation describes a desktop approximation of mobile conditions, rather than code running on the mobile device itself.

Changing the user agent does not close that gap. The Network conditions reference says an override changes how Chrome identifies itself to servers, not how it works internally. You can investigate whether a server delivers different content without testing Safari’s execution of that content.

A layout mismatch therefore does not, by itself, prove that the preset has the wrong width. Separate the simulated display conditions from behavior in the browser you need to support.

Use the device name as a starting point

The October DevTools recap adds presets including iPhone 16, Pixel 9 and Pixel 10, with devices organized by form factor. A newer catalog improves selection; it does not add Safari to Chrome.

Condition	Question to check
Viewport width, height and rotation	Does the layout work at narrow widths and in landscape?
Device pixel ratio	Which ratio of device pixels to CSS pixels are you testing?
Device type and touch setting	Are you checking touch input or mouse clicks?
User agent	Does the server deliver different content for that identity?

Open DevTools, enable Toggle device toolbar and select a device under Dimensions. Use Responsive to vary the width around a layout breakpoint. These checks help isolate responsive behavior before reproducing the same interaction in Safari.

Inspect the page that is running on the iPhone

Prepare both devices, then connect the phone to your Mac:

In Mac Safari, open Settings → Advanced and enable Show features for web developers.
On the iPhone, open Settings → Apps → Safari → Advanced and enable Web Inspector.
Connect the iPhone with a cable. Confirm the Mac trust prompt if the device presents one.
Open the affected page in Safari on the iPhone.
In Mac Safari’s Develop menu, select the iPhone and its page.

The Mac setup is documented by WebKit; the current iPhone settings path and page selection are in Apple’s inspection guide. Closing the inspected phone tab also closes its inspector window.

For example, if a button shifts only in landscape, rotate the phone and inspect its applied styles in that state. That gives you the failing environment rather than another desktop screenshot.

Use a simulator when needed, then finish in the target environment

Apple also supports inspecting iOS Simulator on macOS. Running simulators appear in Safari’s Develop menu with Web Inspector enabled. This is a different route from selecting an iPhone label in Chrome on Windows.

Use Chrome for the initial responsive layout work. Move unresolved Safari differences into Safari, keeping the URL, orientation and failing interaction consistent. The useful completion test is whether the problem is gone in the browser your audience uses.