Why DevTools device mode isn't accurate (and what is)

Chrome DevTools device mode is accurate about exactly one thing: the width and height you give it. Everything around those numbers is an approximation. It hides the browser toolbars, runs Chrome's engine even when the dropdown says "iPhone", uses your computer's fonts and mouse, and its preset list can trail the phones people actually carry.

That doesn't make it useless. You just need to know where the gaps are, and cover them with real sizes and, before launch, a real phone.

What device mode does well

Open DevTools and press Cmd+Shift+M (Mac) or Ctrl+Shift+M (Windows) to toggle the device toolbar. What you get is genuinely good:

• Real layout at the size you type. The page lays out at that CSS width, so media queries, vw units and text wrapping behave as they would at that width. (New to CSS pixels? Start with what a viewport is.)
• A device pixel ratio value. The page is told the DPR you pick, so srcset chooses the same image file a phone would. More in device pixel ratio explained.
• User agent and touch events. Presets send a mobile user agent string and can fire touch events instead of clicks.
• Throttling and sensors. Slow down the CPU and network, fake a location, rotate the screen.
• The inspector, right there. Nothing beats it for finding which CSS rule broke the layout.

Google's own documentation calls device mode "a first-order approximation" of a phone and points you to remote debugging on a real device for the rest. That's the honest framing. Here's what the approximation leaves out.

Where device mode misleads you

1. The preset list trails new phones

The built-in device list is hand-maintained and ships with Chrome updates, so it tends to lag behind new launches and keeps older models around. Before you trust a preset, compare it with what current phones actually give a web page:

If a phone you care about is missing, add it: open the device dropdown, choose Edit, then Add custom device, and enter the width, height, DPR and a mobile user agent.

Two traps when you do. First, don't copy sizes from random "viewport size" websites. Many just divide the panel resolution by a guessed DPR and get it wrong: the iPhone 13 mini is 375 × 812, not 360 × 780. Second, one preset per phone hides user settings. A Galaxy S25 Ultra is 384 px wide by default, but its Display size setting can make it 412, 360 or 320. An iPhone 16 with Display Zoom set to Larger Text is 320 × 693 instead of 393 × 852. People who turn text up are often the first ones your layout fails.

2. No browser toolbars, so the height is too generous

Set up an iPhone 18 Pro and DevTools hands the page all 402 × 874 CSS pixels. A real iPhone doesn't. In Safari on iOS 26, with the toolbars expanded as they are on first load, the status bar and Safari's bottom bar take about 156 px: an iPhone 16 Pro (same size) measured 718 px of visible page out of 874. Android Chrome does the same with a status bar, a 56 px toolbar and a 24 px gesture bar.

Once the visitor scrolls, the bars shrink and the page gains roughly 36 px on iPhone and 80 px on Android. So "above the fold" in DevTools is 120 to 160 px taller than what a visitor sees when your page opens. That's where your main button quietly disappears, and why height: 100vh heroes get cut off. The 100vh fix and how much of the screen iPhone users see in Safari go deeper.

DevTools also never shows an on-screen keyboard, which on a real phone covers a big chunk of the screen the moment someone taps a form field.

3. Desktop scrollbars steal about 15 px

Phone presets mostly avoid this. But if you use Responsive with a desktop device type, or just drag your browser window narrow, classic scrollbars (Windows, or a Mac set to always show them) take about 15 px of width. Your "375 px" test now lays out in roughly 360 px, and anything sized width: 100vw sticks out by the scrollbar's width. That's a sideways-scroll bug phones don't have, because their scrollbars float over the page. If you're chasing overflow that only exists on your desktop, fix horizontal scrolling on mobile covers the real causes.

4. It's still Chrome, whatever the label says

Choosing "iPhone" changes the size and the user agent string. It doesn't swap in Safari. The page still runs in Chrome's Blink engine, while Safari uses Apple's WebKit. That means:

• WebKit-only bugs never show up, and features Chrome supports but Safari doesn't look like they work.
• Safari on iPhone zooms in when you tap a form field whose text is smaller than 16 px. DevTools never does.
• Feature detection (@supports, CSS.supports()) answers for Chrome, while your server may send iPhone-specific code because of the user agent. You're testing a hybrid that no visitor has.

Touch is only partly emulated too. You get touch events, but you're aiming with a precise mouse, so a 28 px link feels easy to hit when a thumb would miss it, and hover and pointer behaviour is only partly emulated. Menus that open on hover need a tap alternative, and only a real phone proves it works.

5. Fonts and pixels come from your computer

System fonts come from your machine. font-family: system-ui is Segoe UI on a Windows PC and San Francisco on an iPhone, and they're different widths, so a heading that fits on one line in DevTools can wrap on the phone. Web fonts you load yourself look the same everywhere; system fonts don't.

DevTools reports the DPR you choose to the page, but you're still looking at your own monitor's pixels, so you can't judge how sharp an image or a hairline border looks on a 3× iPhone screen.

6. One size at a time

Device mode shows one screen. Phones people use today span 360 px (Galaxy S25) to 448 px (Pixel 10 Pro XL), down to 320 px with big-text settings, and then there are tablets and laptops. Checking them one by one is slow enough that nobody does it, so the bug at 360 ships while you admire 402.

What doesitfit does differently

doesitfit was built for exactly these gaps. Paste a URL or your localhost and it shows the site side by side on the exact CSS viewports of real devices, picked from a researched list of 123.

• Researched sizes, including settings. Every size comes from maker specs and measurements, plus the alternative settings people actually use: Samsung Display size, iPhone Display Zoom, macOS "More space", Windows scaling (a Full HD laptop at 125% is 1536 × 864). Browse them all at /devices.
• Browser bars at real heights. Turn on Browser bars to add Safari's or Chrome's toolbars at their typical heights, so you see the 718, not the 874.
• Many screens at once. Phones, tablets and laptops side by side, with Sync scroll.
• Stickers that measure overflow. Each screen says FITS, TIGHT (text within 8 px of the edge, or cut off) or SPILLING +Npx. Click one for Show me where and a Copy fix prompt for your AI. On your own site you add one line of script once so the page can report its size (the app gives you a prompt for that); other sites still show, marked "not measured".
• Mockups. Real phone frames, including notches, Dynamic Islands and the iPhone Duo's side strip.

Its honest limits

doesitfit runs in your desktop browser too, so some of the same caveats apply:

• The engine is whatever you open it in. In Chrome that's Blink; in Safari on a Mac the previews use WebKit, which is closer to an iPhone but still not iOS.
• Fonts and DPR come from your computer, your mouse still hovers, and always-on scrollbars take about 15 px from each screen.
• Some sites refuse to be shown inside other sites and show BLOCKED. Your own site normally allows it; X-Frame-Options and frame-ancestors explains why.
• Toolbar heights are typical first-load values. On a real phone they shrink as you scroll.

Use both, then a real phone

They do different jobs:

1. While building: DevTools. Inspect, tweak CSS live, check one size at a time.
2. Before you share or merge: doesitfit. Load a set like "Smallest → largest phones" plus a tablet and a laptop, turn on Browser bars, and fix anything SPILLING or TIGHT.
3. Before launch: a real iPhone and a real Android. Fill in a form, open the menu, rotate, scroll to the bottom. Borrow one if you have to. Testing on mobile without a phone covers simulators, and opening localhost on your phone gets your dev server onto it.

If you build with AI, hand the most common DevTools blind spot straight over:

My site looks fine in Chrome DevTools, but on a real iPhone the hero section is cut off and the main button is below the fold. Replace any 100vh heights with 100svh (keep 100vh as a fallback line before it), and make sure the main button is visible within the first 700px of a 402 × 874 screen.

The short version

• DevTools is exact for the width you type. Everything else is an approximation.
• Use real sizes from /devices, not whatever presets happen to be there.
• Subtract the toolbars: about 156 px on a modern iPhone and 120 to 150 px on Android on first load.
• Check many sizes at once, then finish on a real phone.