Your site looks perfect. You've checked it a dozen times — on your laptop. But the laptop is the one screen your visitors almost never use. Most of them arrive on a phone you don't own, running a browser you've never opened, and that's exactly where layouts quietly fall apart.
This guide walks through every real way to see your website on a real iPhone and Android — including the free, ~60-second option most people don't know exists — and the honest trade-off of each.
Why "it works on my machine" isn't enough
A 27-inch monitor and a 390-pixel phone are different worlds. On a real device a headline wraps one extra line and shoves your call-to-action off the screen; a cookie banner covers the page with no way to dismiss it; a dropdown opens behind the on-screen keyboard; an image 404s and collapses the layout. None of it reproduces on your desktop — which is exactly why you never see it and your customer does.
The screen you built on is the screen your users almost never have. The only way to know how your site really looks is to open it on the devices they actually use.
Option 1: Buy the devices
The obvious answer, and the worst. A current iPhone, a Pixel, a budget Android, an iPad — that's easily over a thousand dollars, and it's out of date in a year. You'll still be missing the two-year-old Android on a slow connection that a chunk of your traffic actually uses. Real device labs exist for a reason, but they're for companies with a QA headcount, not for someone shipping a site this week.
Option 2: Your browser's "device mode"
Chrome and Safari both let you fake a phone viewport in DevTools (open DevTools, then the little phone icon). It's free and instant and genuinely useful for a first pass. But be clear about what it is: a simulation, not a real device. It resizes the window and swaps the user-agent string — it does not render with the phone's real browser engine, system fonts, webview quirks, or memory limits. Many of the bugs that only come from the actual device simply don't appear in device mode.
Option 3: Ask a friend (or a customer)
Text a few people on different phones and ask for a screenshot. It works, sort of. It's also slow, it relies on favors, and you only hear about a bug after someone happens to notice it — by which point it's been live for days.
Option 4: A device cloud like BrowserStack
Services like BrowserStack and LambdaTest give you real hardware in the cloud — you remote-control an actual iPhone or Pixel from your browser. This is the real thing and it's great. The catch: you drive it manually, one device at a time, and the useful plans aren't free. For a quick "is my site broken on mobile?" check before a deploy, it's more setup than the moment calls for.
Option 5: Paste your URL into a scanner (free, ~60 seconds)
Here's the option most people miss. Instead of driving a device yourself, you hand a URL to a scanner that opens your page on real iPhone, Pixel, and Desktop profiles at once, screenshots each one, and tells you exactly what's broken — ranked by severity, with a copy-paste fix for each finding.
That's what we built Canaryflux to do. Nothing to install, no tests to write, and no account needed to see your first result:
- Paste a URL you own (or any public page).
- It opens on real device profiles and captures full-page screenshots, console errors, and network failures from each.
- An AI vision pass grades every finding — Blocker, Major, Minor — and writes the one-line fix.
- You get the report in about a minute: the bug, the device it broke on, and how to fix it.
It catches what device mode misses and CI screenshots never see: the sign-up button clipped off the right edge on a Pixel, the hero image that 404s and collapses the fold, text that's unreadable at low contrast, a menu that opens off-screen.
The fastest way to check your site right now
If you just want to know how your site looks on a real phone before your next deploy, the shortest path is simple: paste the URL, wait about a minute, read the ranked findings. Free, no Mac, no device lab, no account needed to see the first result.
We'd rather you find the broken button than your customer.