You're working on a responsive layout, checking it on desktop, everything looks perfect. You open it on a smartphone, the layout breaks, the font becomes the size of a matchstick head, and the "Pay" button slides off the edge of the screen.

Product giants with budgets for QA labs can afford to buy a fleet of real devices for every screen. But what should a freelancer, a three-person startup, or a solo developer do? The answer is Chrome's built-in DevTools emulator. Free, launches with a single keyboard shortcut, and covers the vast majority of everyday responsive testing tasks. No additional software to install, no virtual machines, no cloud farms.

Below is a step-by-step guide to Device Mode: from activation to fine-tuning network throttling and sensor emulation. Everything you need to test a site on smartphones and tablets without leaving your work laptop.

💡 Quick overview:

• Open DevTools (F12 or Ctrl+Shift+I) and enable the Device Toolbar (Ctrl+Shift+M), the page will switch to mobile viewport emulation mode.
• Select a specific model from the dropdown list (iPhone, Pixel, Galaxy) or set a custom resolution in pixels, Chrome will automatically apply the appropriate user agent.
• Configure network throttling (Slow 3G / Fast 3G) and enable touch emulation to see how the site loads and interacts with users on real mobile internet.
• Remember the limitations: the emulator doesn't reproduce the hardware GPU of a specific device, iOS font rendering, or Safari WebKit behavior, a real phone is still necessary for final testing.

What Device Mode is and when it's enough

Device Mode is a set of tools inside Chrome DevTools that emulates viewing a page on a mobile device. It does three things simultaneously:

• Emulates the viewport, compressing the viewing area to the physical screen dimensions of the selected device. You see the site as a user of an iPhone 16 Pro Max or Samsung Galaxy S25 would see it.
• Spoofs the user agent, the server receives a string typical of a mobile browser. Critical for sites with dynamic serving that deliver different layouts to desktop and mobile.
• Enables touch emulation, the mouse cursor turns into a finger simulation, with support for touch events, gestures, and multi-touch.

Let's immediately establish the boundaries. Device Mode does NOT emulate: the Safari rendering engine (WebKit), hardware acceleration GPU of a specific model, battery behavior and background OS processes, or cellular network behavior of different carriers. For the final acceptance test before release, a physical phone is still needed. But for daily development and debugging, the tool covers needs with room to spare.

How to open Device Mode: three methods

Chrome offers several paths to the emulation panel. Choose the one that's faster in your workflow.

Method 1. Keyboard shortcuts, the fastest

While in Chrome, press:

• Windows / Linux: Ctrl + Shift + M
• macOS: Cmd + Shift + M

If DevTools isn't open yet, it will open automatically along with the emulation panel. Pressing again disables Device Mode and returns the page to normal view.

Method 2. Button in DevTools

Open DevTools (F12 or Ctrl+Shift+I). In the upper left corner of the panel, next to the Elements tab, there's a phone and tablet icon, Toggle device toolbar. Click it.

Method 3. through Chrome's main menu

Three dots in the upper right corner of the browser → More Tools → Developer Tools. Then, the Device Toolbar button, as in method 2. The path is longer, but it saves you if keyboard shortcuts slipped your mind in the middle of a midnight deployment.

Device selection and emulation settings

After enabling the Device Toolbar, the page will reload and a control panel will appear above it. Let's break down each element.

Device dropdown list

The central element, a dropdown list with preset profiles. Chrome ships with about fifteen presets: from iPhone SE (for checking compact screens) to iPhone 16 Pro Max, from Pixel 9 to Galaxy S25.

Select a device, and Chrome in one step:

• sets the viewport width and height;
• applies the corresponding user agent;
• enables touch emulation (unless manually disabled).

To add a device that's not in the list, click Edit... in the same dropdown menu and fill out the form: screen resolution, Device Pixel Ratio, user agent string. The custom profile will appear in the general list.

Manual resolution

Don't want to tie yourself to a specific model? Enter arbitrary numbers in the width and height fields. Typical scenario: "how does the layout look on a standard mid-range Android smartphone?", you enter a typical resolution and instantly get the answer, without searching for the right model in the list.

Device pixel ratio

DPR determines how many physical screen pixels correspond to one CSS pixel. Modern flagships have DPR = 3, tablets and budget phones have 2. In the Chrome emulation panel, it shows the current DPR value for the selected device and allows you to change it through the dropdown list. This directly affects the sharpness of images and SVG icons on retina displays.

Screen rotation, network throttling and sensors

Three additional settings that turn Device Mode from a simple "magnifier" into a full-fledged testing tool.

Screen rotation

The icon with two circular arrows swaps width and height. Always toggle portrait ↔ landscape on every key screen: site header, product card, payment form. Horizontal scrolling on a landing page in portrait orientation is a critical error that the client will notice faster than you.

Network throttling

The No throttling dropdown allows you to limit loading speed. Available presets:

• Slow 3G (400 Kbps), poor mobile internet in the subway, outside the city, or in a basement;
• Fast 3G (1.6 Mbps), typical mobile internet in the city;
• Slow 4G and Fast 4G (4-25 Mbps), good connection.

After selecting a profile, refresh the page and look at the timings in the Network panel. If fonts or hero images load longer than three seconds on Fast 3G, a user on slow internet has already left for a competitor.

Touch emulation

Enabled by default when selecting a mobile device. The cursor turns into a translucent circle, simulating a finger tap. Check three things:

• do dropdown menus work on tap, not on hover;
• is the size of interactive elements sufficient, according to WCAG 2.1, the minimum touch target is 48×48 CSS pixels;
• are there no false hover effect triggers that are physically unreproducible on a real phone.

Geolocation, media queries and sensors

Chrome has hidden several useful tools in the "three dots" menu (⋮) inside the DevTools panel, in the More tools section.

Geolocation

The Sensors tab (More tools → Sensors) allows you to set arbitrary latitude and longitude coordinates. A site using the Geolocation API will receive the specified point instead of the real one. Convenient for checking regional prices, automatic interface language detection, and local promotions.

Media queries

The Rendering panel (More tools → Rendering) shows CSS media query breakpoints directly over the page. Enable the Show media queries flag, a colored scale with style switching marks will appear above the page. Clicking a point instantly sets the viewport to the corresponding width. An indispensable thing when debugging complex breakpoints.

prefers-color-scheme and prefers-reduced-motion

Also in the Rendering panel are toggles:

• prefers-color-scheme, forces light or dark theme regardless of OS settings;
• prefers-reduced-motion, emulates a request to disable animation, critical for accessibility testing.

Screenshots and screencast recording

Device Mode can take screenshots of the emulated page. Three dots in the Device Toolbar panel → Capture screenshot, and you get a PNG exactly the size you see on screen. For a screenshot of the full page height, choose Capture full size screenshot, useful for sending the layout to a client or in a bug report.

If static screenshots aren't enough, Chrome records a screencast of working with the emulated page. Open the Recorder panel (More tools → Recorder), create a new recording and perform actions, Chrome will record every step with timestamps. The finished recording can be exported as a Puppeteer script and automate re-testing after edits.

Limitations: when you can't do without a real device

Chrome emulation is a powerful tool, but not a silver bullet. Here's what it fundamentally doesn't cover:

• iOS rendering. According to Apple App Store rules, all browsers on iPhone and iPad must use the WebKit engine, even Chrome and Firefox are technically wrappers over Safari WebView. DevTools shows the rendering of the Chromium engine (Blink), and differences in font display, rounding, shadows, and filters between Blink and WebKit can be significant.
• Hardware sensors. Gyroscope, barometer, NFC, hardware video acceleration, none of this exists in the emulator, and the corresponding APIs will return null or an error.
• Low battery behavior. iOS and Android aggressively unload background tabs at critical battery levels. The emulator doesn't reproduce this.
• Real JavaScript performance. A mobile processor is many times slower than a desktop one, animations "flying" on a work laptop can freeze on a mid-range phone. For measurement, use Lighthouse with CPU throttling.

The rule is simple: conduct the entire development and layout cycle in Device Mode, and perform the final check of each release on at least one physical Android device and one iPhone.

A short but packed video from the Chrome Developers team: Jecelyn Yeen shows five ways to emulate mobile viewport, from basic switching to custom device profiles and touch testing.

⁉️🤔 Frequently asked questions

Why does the site look different in Chrome DevTools and on a real iPhone?

Chrome on all platforms except iOS uses the Blink engine. A real iPhone runs on WebKit, these are two different rendering engines with different handling of fonts, smoothing, CSS filters, and shadows. That's why the final test for iPhone requires a physical device, the emulator will show the picture "as in Chrome on Mac", not "as in Safari on iPhone".

What's the difference between emulation and simulation in the context of DevTools?

Emulation reproduces system behavior at the API and protocol level: spoofs the user agent, emulates touch events, limits network bandwidth at the browser level. Simulation is a more superficial imitation that doesn't affect low-level mechanisms. Device Mode in Chrome is precisely emulation, not simulation.

Can you emulate a specific version of iOS or Android?

No. Device Mode emulates viewport, user agent, and touch input, but not the operating system and not the browser engine version. The user agent can be manually spoofed through Network conditions → User agent, but the rendering will still remain Blink-based. To test under a specific Safari/iOS version, you need either a physical device or a cloud service like BrowserStack.

How to test a PWA or Service Worker in the emulator?

Open the Application panel in DevTools. In the Service Workers section, check the Update on reload flag and mark Bypass for network if necessary. The emulator supports offline mode, enable it with the Offline checkbox on the Network tab or in the Service Workers panel. The PWA manifest is checked in the Manifest tab, also in the Application panel.

What to do if the Device Toolbar isn't active, the icon is gray?

The most common reason is you're on a Chrome service page (chrome://extensions, chrome://settings, DevTools new tab). Device Mode only works on regular web pages. Open any http/https page and try again.

What to do when the emulator isn't enough

Device Mode in Chrome DevTools covers the lion's share of responsive layout tasks: viewport switching, network throttling, touch input, geolocation, media queries, screenshots. For the daily work of a freelancer or a small team, this set is more than enough.

But remember the boundaries. iOS rendering, hardware sensors, real JS performance on weak mobile hardware, all of this remains beyond emulation. The gold standard: write and debug the layout in Device Mode, and before each release, go through checkpoints on a physical iPhone and Android smartphone. Two devices, fifteen minutes, and the confidence that the user will see the site as you intended it.