Test your website on iPhone, with Safari's engine (WebKit)

Most people who build websites do it on a laptop with Chrome open. Their visitors, on the other hand, are often holding an iPhone, and every browser on iPhone draws pages with WebKit, the engine behind Safari. If you have only checked your site in Chrome, you have only seen half the picture.

MobileCheck loads your page in WebKit, Safari's engine, on our servers, sized and configured like the iPhone you pick, and gives you full-page screenshots plus a list of problems explained in plain English.

Why Chrome's iPhone mode is not Safari

Chrome DevTools has a handy device toolbar where you can choose "iPhone 14 Pro" from a menu. It changes the screen size, the pixel ratio and the user agent, but the page is still drawn by Chromium, Chrome's engine. That is fine for checking breakpoints. It is not fine for catching the bugs that only Safari has. The usual suspects:

• Fonts. On Apple devices system-ui and -apple-system resolve to San Francisco, and WebKit rasterizes and spaces text differently from Chromium. A heading that fits on one line in Chrome can wrap in Safari, or a button label can get clipped.
• Form controls. Safari gives inputs, selects and buttons its own default look: rounded corners, inner shadows, different padding. If you rely on browser defaults, your form will look different on iPhone. Inputs with a font size under 16px also make Safari zoom in when they get focus.
• 100vh and the toolbar. In Safari on iPhone, 100vh equals the tallest possible viewport, the one you get after the address bar collapses. With the toolbar showing, a "full-screen" hero is taller than the screen and its bottom is hidden. The newer dvh, svh and lvh units fix this, but only if you use them.
• position: fixed. Fixed headers and bottom bars behave differently on iOS when the on-screen keyboard opens or the toolbar resizes, and a sticky bar can end up covering the content it should frame.
• Date and time inputs. iPhones show native wheel pickers with their own sizing and styling, not the calendar popup you see on desktop.
• -webkit- features. Some properties have needed the -webkit- prefix in Safari for years, such as -webkit-backdrop-filter in older versions, and Safari's support for newer CSS can lag behind or run ahead of Chrome's. A feature that works in Chrome may simply be ignored.

Rendering with WebKit catches the engine differences: how text is laid out and wraps, which CSS features and -webkit- properties work, and layout bugs that only WebKit has. The parts that come from iOS itself rather than the engine, such as the San Francisco font, native form controls and date pickers, the zoom when you tap a small input, the toolbar resizing 100vh as you scroll and the on-screen keyboard, need a real iPhone. MobileCheck tells you which is which and keeps the space Safari's bars take into account.

How MobileCheck tests your site on iPhone

When you pick an iPhone, the check runs in WebKit with that model's real CSS viewport, pixel ratio, touch input and a Safari user agent. We also subtract the space Safari's status bar, address bar and toolbar take up, so you see what is actually visible when the page opens, not the whole glass.

Each page is loaded once per device and checked in four scenarios: normal, dark mode, large text at 150%, and with the mobile menu opened. The report has a full-page screenshot for each device, a score from 0 to 100, and every problem marked on the screenshot with what it is, why it matters and how to fix it. You also get lab measurements of Largest Contentful Paint, layout shift and page weight.

Which iPhone sizes matter

iPhones come in fewer sizes than Android phones, but there are still several distinct widths in use. A practical set to test:

• 375px: iPhone SE (2nd and 3rd gen), iPhone 7 and 8, and the 12 and 13 mini. The narrowest iPhones still in common use.
• 390px and 393px: iPhone 12 to 14, and the iPhone 14 Pro, 15 and 16. This is the mainstream size.
• 402px: iPhone 16 Pro and the iPhone 17 line.
• 430px and 440px: the Plus and Pro Max models, the widest phones Apple makes.
• 820px and up: iPads, which request the desktop version of sites by default.

Width is not the whole story. Older iPhones with a Home button have a much shorter screen, so content you expect "above the fold" may be off screen. Newer models have a notch or Dynamic Island, which changes how much room Safari leaves at the top. Our mobile viewport sizes table lists every model with its width, height and pixel ratio.

What iPhone problems we catch most often

The same handful of issues come up again and again:

• A hero section sized with 100vh that hides its button below the Safari toolbar.
• Body text below 16px that is fine on a laptop but tiring on a phone. See text too small to read.
• Links and buttons too small or too close together to tap reliably. See tap targets.
• Something wider than the screen, so the whole page wobbles sideways. See content wider than the screen.
• A sticky header plus a cookie banner that together cover a large part of a small screen.

Honest limits

MobileCheck runs WebKit on our servers. It is not a physical iPhone, and it is not the exact Safari build Apple ships with iOS. Rendering is very close, but a few things are out of reach: Apple Pay, Safari extensions, iOS system dialogs, the exact behaviour of the on-screen keyboard, and anything that depends on iOS hardware such as Face ID or the camera. For a final check before an important launch, nothing beats opening the page on a real iPhone. For catching layout and readability problems quickly, across several iPhone sizes at once, a WebKit render gets you most of the way there.

If you want to tap around rather than read a report, the online iPhone simulator streams the same WebKit browser to your screen so you can scroll, tap and type on your own site.