How to test your website on an iPhone from Windows

You can't run real iPhone Safari on Windows: Apple's iOS Simulator needs a Mac with Xcode, and Safari for Windows stopped years ago. What you can do from a PC is check your site at exact iPhone viewports (including Safari's toolbars), render it with WebKit, Safari's engine, for free through Playwright, and save a real iPhone, borrowed or in the cloud, for the final check.

Here's what each option catches, what it misses, and a routine that covers the gaps.

The honest situation

Three facts shape everything else:

1. Every iPhone browser is WebKit. Apple's App Review Guidelines (rule 2.5.6) require browsers on iPhone to use WebKit, with exceptions only for approved alternative engines in the EU and Japan. So Chrome on an iPhone mostly behaves like Safari, not like Chrome on your PC, which uses Google's Blink engine.
2. The iOS Simulator is Mac only. It ships with Xcode, which only runs on macOS.
3. Safari for Windows is dead. Apple's own support page says Safari 5.1.7 was the last version made for Windows and that it's outdated. Don't download old copies from random sites: its engine is over a decade old and unpatched.

So on Windows you're approximating. The trick is knowing which approximation catches which bug:

Option 1: iPhone-sized previews in your browser

Most mobile bugs are about size, not engine: a fixed width, a giant heading, a row that doesn't wrap. You catch those at the right viewport in any browser.

doesitfit

doesitfit shows your site at the exact CSS viewports of real devices, side by side: from the iPhone SE at 375×667 to the iPhone 17 Pro Max at 440×956, plus Android phones, tablets and laptops. Pick the "Current iPhones" set to see the iPhone 17e, 17, Air, 17 Pro and 17 Pro Max at once.

What helps most for iPhone testing:

• Browser bars draws the status bar and Safari's toolbar at their real heights. On an iPhone 17 Pro (402×874), that leaves 718px of the 874px height for your page on first load, which is where "my button is hidden" bugs show up. More in how much of the screen iPhone users see in Safari.
• Stickers: FITS, TIGHT (text within 8px of the edge) or SPILLING +Npx (the page is N px wider than the screen), with Show me where and Copy fix prompt. They need a one-line snippet on your site, and the app gives you a prompt that adds it.
• Localhost: paste localhost:3000 and click Allow when Chrome asks about your local network.

The honest limit: previews are drawn by your own browser. In Chrome or Edge on Windows that's Blink, with Windows fonts, not WebKit with Apple's. And if your PC shows classic scrollbars, a scrolling page loses that width in each preview; the app tells you how many pixels when that's the case.

Chrome or Edge DevTools device mode

Press F12, then Ctrl+Shift+M. Type a real size instead of trusting the preset list: 402×874 for an iPhone 17 Pro, 375×667 for an iPhone SE.

Google's own docs call device mode a "first-order approximation". The "iPhone" preset changes the size and user agent; it's still Chrome underneath, with no Safari toolbars. The full list of gaps is in why DevTools device mode isn't accurate.

Option 2: Real WebKit on Windows with Playwright (free)

Playwright is Microsoft's open-source browser automation tool. It ships its own build of WebKit, and it runs Chromium, WebKit and Firefox on Windows, Linux and macOS. That makes it the one free way to see your page drawn by Safari's engine on a PC.

You need Node.js. Playwright's docs list Windows 11 or WSL as the requirement. Then, in a terminal:

npx playwright install webkit
npx playwright open --browser=webkit --device="iPhone 17 Pro" http://localhost:3000

A WebKit window opens at iPhone size with touch and an iPhone user agent, and you can click around your site. localhost works as is, because it runs on your PC. If your Playwright version doesn't know that device name, update it or pick an older one such as "iPhone 15".

For quick side-by-side checks, take screenshots instead:

npx playwright screenshot --browser=webkit --device="iPhone SE (3rd gen)" --full-page http://localhost:3000 iphone-se.png

What it is and isn't:

• It's WebKit, not Safari. Playwright's docs say its WebKit is built from the latest WebKit sources, often ahead of Safari, and it can't drive branded Safari. So it catches the "works in Chrome, broken in WebKit" class of bug, not every Safari quirk.
• WebKit on Windows isn't WebKit on a Mac. Features that depend on the operating system vary (Playwright's docs give media codecs as the example), and the docs recommend a Mac for the closest-to-Safari results.
• No iOS around it. No Safari toolbars, no iOS fonts, no on-screen keyboard. Device presets set the width right; the height is Playwright's own estimate (681px for the iPhone 17 Pro), not the 718px Safari shows on first load.

Rather not touch the terminal? Ask your AI:

Set up Playwright in this project for WebKit only, as a dev dependency. Add a script, npm run iphone, that opens [/, /pricing, /signup] in WebKit with Playwright's "iPhone 17 Pro" and "iPhone SE (3rd gen)" device presets and saves full-page screenshots to a screenshots folder. Don't add anything to the production build.

Option 3: Cloud iPhones and cloud Macs

Two kinds of service fill the gap for people without Apple hardware:

• Real-device clouds run racks of physical iPhones and stream the screen to your browser. You get real Safari on real hardware, including models and iOS versions nobody on your team owns.
• Cloud Macs give you a remote macOS desktop, so you can install Xcode and use the iOS Simulator and Safari's Web Inspector as if you had a Mac.

The catches are the same for both: they're mostly paid, sessions are laggy, and to test localhost you install the provider's tunnel. For client work, check you're allowed to send an unreleased site to a third party. They earn their keep when a bug only happens on one model, or when you need a proper inspector on a real iPhone.

Option 4: A borrowed iPhone (and the Mac problem)

Five minutes on a friend's iPhone catches what nothing else does. To open your dev site on it, use your PC's IP address on the same Wi-Fi or a tunnel: how to open localhost on your phone walks through both.

Debugging is harder. Apple's Web Inspector for iPhone needs Safari on a Mac, connected by cable or wireless debugging set up in Xcode. On Windows, unofficial tools such as ios-webkit-debug-proxy can talk to an iPhone over USB, but setup takes patience.

The low-tech alternative is an on-page console. Eruda is an open-source console that draws itself inside the page, so you can read errors on the phone itself. Load it only when you ask for it:

<script>
  if (new URLSearchParams(location.search).has('debug')) {
    const s = document.createElement('script');
    s.src = 'https://cdn.jsdelivr.net/npm/eruda';
    s.onload = () => eruda.init();
    document.head.appendChild(s);
  }
</script>

Open yoursite/?debug on the iPhone and a small button opens the console. Keep this in development builds only.

On the real phone, check what only a real phone shows:

• Tap into every form field. If Safari zooms in, the text is under 16px: see why iPhone zooms in on your form.
• Scroll to the bottom and back. Safari's bars shrink and grow, which moves anything sized with 100vh (100vh on mobile is broken).
• Open the menu, rotate the phone, tap the smallest link with your thumb.

A routine that works from Windows

1. While building: Chrome or Edge with device mode at 402×874 and 375×667 for quick CSS fixes.
2. After every big change: doesitfit with the "Current iPhones" set and Browser bars on, then the "Smallest → largest phones" set. Fix SPILLING first, then TIGHT. If you'd rather stay in your AI chat, the doesitfit MCP server runs the same check from Claude, ChatGPT or Codex.
3. Before each release: a Playwright WebKit pass over your key pages at iPhone 17 Pro and iPhone SE sizes. Compare the screenshots with Chrome's.
4. Before launch: a real iPhone, borrowed or in the cloud, for forms, fonts and scrolling.

When the WebKit screenshot and the Chrome one disagree, give your AI the details:

In WebKit (Playwright, "iPhone 17 Pro" preset, 402px wide) the [pricing cards] on [/pricing] look different from Chrome: [the gap between cards is missing and the last card overflows]. Find the CSS that WebKit handles differently and change it so both engines render the same. Check Safari support on MDN for any CSS feature you rely on, keep the desktop layout unchanged, and list what you changed.

For the wider picture of testing without any phone, including Android emulators, see how to test your website on mobile without a phone.

What to take away

• Real iPhone Safari needs Apple hardware: a Mac, a cloud Mac, or an iPhone.
• Most iPhone bugs are size bugs. Catch them at exact viewports with Safari's toolbars, from any browser.
• Playwright's WebKit is the free way to see Safari's engine on Windows. Treat it as "WebKit", not "iPhone".
• Finish on a real iPhone before launch. Browse every model's size on the iPhone devices page.