Safari vs Chrome: see where your site differs on iPhone

If your site looks right in Chrome on your laptop but a client says it's broken on their iPhone, the two browsers are drawing it differently. Every browser on an iPhone uses WebKit, the engine behind Safari; Chrome's iPhone mode in DevTools only resizes Chromium. MobileCheck renders the same iPhone screen in both engines and puts the screenshots side by side, with the differences marked.

How the comparison works

Tick Safari vs Chrome (iPhones) in the check form. For each iPhone or iPad you pick, the page is loaded twice with the identical device profile — the same CSS viewport, pixel ratio, user agent, touch input and space for Safari's bars:

• once in WebKit, Safari's engine, which runs the full check (normal view, dark mode, large text and the opened menu);
• once in Chromium, the engine behind Chrome's device mode, for the normal view only.

The report gets a Safari vs Chrome tab. For each device it shows both screenshots, the page height and width in each engine, the average text size, and the problems that appear in only one of them. Highlight differences compares the two pictures in your browser and marks every area where they differ, so a heading that wraps in Safari but not in Chrome, or a button that drops below the fold, stands out at once. The comparison doesn't change your score: it's there to explain, not to judge.

What usually differs between Safari and Chrome

• Text layout. The engines measure and wrap text slightly differently, especially with web fonts, letter-spacing and text-wrap: balance. One extra line in a heading moves everything below it.
• CSS support. Newer features arrive in the two engines at different times. A property Chrome supports may simply be ignored by the Safari version your visitors have, and some properties still need a -webkit- prefix in Safari.
• Flexbox and grid edge cases. min-height on flex children, gap with older Safari, aspect ratios and images inside grid cells are classic sources of differences.
• Form controls. Inputs, selects and buttons get each engine's default styling unless you reset it.
• Sticky and fixed elements. position: sticky inside overflow containers and fixed bars behave differently in the two engines.

Some iPhone behaviour comes from iOS rather than from WebKit, so neither engine on a server shows it: the San Francisco system font, native date pickers, the zoom when you tap a small input, and the on-screen keyboard. For those, a real iPhone is still the final check. Our guides on text size and 100vh on mobile explain the most common ones.

When to use it

• A client or user reports a layout bug "on iPhone" that you can't reproduce in Chrome.
• Before launch, as a quick look at your most important pages in Safari's engine without a Mac or an iPhone.
• After adopting a new CSS feature, to see whether Safari draws it the way Chrome does.

It takes about twice as long as a normal check for each iPhone, so pick one or two iPhones rather than all of them.