Switching between desktop and mobile view in Chrome

The request sounds like one thing and turns out to be two. On a Mac, wanting to see the mobile version of a page almost always means checking work: a layout, an email template, a form, a client site that behaves oddly on phones. On a phone, wanting the desktop version usually means a site has hidden something in its mobile layout, and the missing button is on the full version. The two situations use completely different mechanisms, and the settings that fix one are not present on the device where the other happens.

Which of the two situations is on the table

The first is simulation. A desktop browser is asked to render a page as though the viewport were 390 pixels wide, with a touch cursor and a mobile user agent string. Nothing about the machine changes. Chrome pretends, and the page responds to the pretence.

The second is a request. A phone browser asks the server for the version it would send to a laptop. The device does not change either, but the page that arrives is different, and the site's own layout rules then apply to a narrow screen.

Simulation lives in Chrome DevTools and exists only on the desktop. The request setting lives in Chrome's mobile settings and exists only on Android, iPhone and iPad. Looking for a mobile view toggle in the desktop menu, or a device toolbar on a phone, is the most common reason this search happens twice.

Simulating a phone on a Mac

Chrome DevTools includes a group of features that Google calls device mode. Two keystrokes get there.

Open DevTools with Command+Option+I. Then toggle the device toolbar with Command+Shift+M. The page area shrinks into a resizable frame with a control bar above it.

The Dimensions drop down opens in Responsive by default. Drag the handles, or type a width and height directly. There is also a preset bar covering common widths: Mobile S at 320px, Mobile M at 375px, Mobile L at 425px, Tablet at 768px, Laptop at 1024px, Laptop L at 1440px and 4K at 2560px. Selecting a named device from the same list applies that device's dimensions instead.

Three controls matter more than most people realise.

Device Type decides whether Chrome renders the page as a mobile or a desktop viewport, which cursor appears, and whether the page receives touch events or click events. The four options are Mobile, Mobile with no touch, Desktop, and Desktop with touch. If the list is not visible, it can be added from the More options menu on the toolbar. A page that looks correct but does not respond to taps in the simulation is often a Device Type mismatch rather than a bug.

Add device pixel ratio puts a DPR selector on the bar. Device pixel ratio is the ratio between physical screen pixels and logical CSS pixels, and it is what decides which image a responsive image set actually loads. Testing artwork without setting it produces the wrong answer.

Show media queries draws bars above the viewport with the breakpoints found in the page's stylesheets. Blue for max-width, orange for min-width. Clicking between two breakpoints jumps the viewport to that range, and right clicking offers to reveal the matching media rule in the Sources panel. That is considerably faster than dragging a handle and watching for the moment the layout jumps.

What the simulation does not reproduce

Chrome's own documentation is direct about the limits.

Think of device mode as a first-order approximation of how your page looks and feels on a mobile device. With device mode you don't actually run your code on a mobile device. Source: developer.chrome.com

The same page notes that mobile CPU architecture is very different from laptop and desktop CPU architecture, which is why a page that feels smooth in the simulated viewport can still stutter on the actual handset. Where certainty matters, Chrome points to remote debugging: connecting a real phone and inspecting the page while it genuinely runs there.

There is a second gap that catches people more often. Some sites decide what to send based on the user agent string on the server, before any CSS runs. Device mode does send a mobile user agent when a named device is selected, so many of those sites will switch. Sites that also check screen resolution, that redirect to a separate mobile address, or that cached a decision in a cookie during an earlier visit will not. When a page refuses to change, opening it in a new incognito window with device mode already on removes the cookie from the equation and usually settles the question.

The controls that sit next to device mode

Device mode is described by Google as a collection of DevTools features rather than a single switch, and the neighbouring controls answer questions that the viewport alone cannot.

CPU throttling and network throttling both live in DevTools and change how the simulated page behaves under load. Network conditions can also be set from the Network panel, which is the faster route when only the connection speed is in question. Neither of these makes the laptop slower in any real sense. They apply artificial limits so that a page can be watched under pressure.

The Sensors panel handles two more things that matter for phone layouts: simulating a location, and setting the screen orientation. Orientation is also available directly on the device toolbar through the rotate control, which flips the viewport to landscape. Testing a form in landscape is worth doing, because that is the orientation where a fixed header and an on screen keyboard most often collide.

None of these panels are enabled by default beyond the basics, and the toolbar hides several of them. The More options menu at the end of the device toolbar is where Device Type, device pixel ratio and the media query bars are added. A toolbar that looks minimal is usually just a toolbar with those items switched off.

Checking a page that requires a login

Simulating a phone on a page behind a sign in adds a wrinkle that catches people out. Device mode does not change the session. The page renders at phone width using whichever account the current profile is signed in to, so an admin view and a customer view cannot be compared in the same window at the same time.

The workarounds are all about separating sessions rather than viewports. An incognito window holds a second, independent session and is the quickest option for a one off comparison, though nothing persists after it closes. A second browser profile keeps both sessions alive across restarts. A browser that gives each service its own window with its own stored session does the same thing without profile switching, which matters when the comparison has to be repeated daily rather than once.

Whichever route is taken, the important detail is that the layout question and the account question are separate. Device mode answers the first and has no effect at all on the second.

Asking for the desktop version on a phone

This is a setting rather than a developer tool, and Chrome lets it be set once rather than per visit.

On Android, open Chrome, tap More to the right of the address bar, then Settings. Under Advanced, choose Site settings, then Desktop site. Default view lets Chrome pick based on screen size and the amount of RAM in the device. Mobile site always requests the mobile version. Desktop site always requests the desktop version. Individual sites can be given their own behaviour through the site exception list on the same screen, which is the setting worth knowing: one stubborn site can be pinned to desktop without changing anything else.

On iPhone and iPad, open Chrome, tap More, then Settings, then Content settings, then Default site view, and choose Mobile or Desktop.

For a single page rather than a permanent rule, the More menu has a Desktop site item that applies to the current site only.

Android's large screen behaviour is worth knowing if a phone or tablet is ever plugged into a monitor. Chrome's help describes a desktop browser experience on a connected large screen, with a full toolbar and tab strip that adjusts to the monitor, and states that by default the full desktop version of websites is shown on devices with 8GB or more RAM, with over 20 windows manageable at once across all connected displays.

Goal	Device	Where the control lives
See a phone layout	Mac	DevTools device toolbar, Command+Shift+M
Test touch behaviour	Mac	Device Type set to Mobile in device mode
Check which image loads	Mac	Add device pixel ratio, then set DPR
Read the full site once	Phone	More menu, Desktop site
Always get the full site	Phone	Site settings, Desktop site, Default view
One site only	Android	Desktop site, add site exception

When the view keeps flipping back

Three causes account for almost all of it.

A per-site exception outranks the global default, so a site set to mobile earlier will stay mobile even after the default is changed. The exception list is on the same settings screen and has to be cleared there.

A separate mobile address is the second cause. Sites that redirect to a different host for phones will often send the phone straight back there on the next navigation, because the redirect happens before the desktop preference is read. Landing on the desktop version and then losing it after one click is the signature of this.

The third is layout rather than delivery. A site with a single responsive stylesheet has no separate desktop version to send. Requesting one produces a wider viewport and nothing else, and the mobile arrangement stays because the arrangement is a function of width. Pinching to zoom is the only remaining lever, and on those sites it is the correct answer rather than a workaround.

When both views are part of the day

Checking two renderings occasionally is a two keystroke job. Doing it forty times a day is a different problem, and it usually arrives alongside several others: a staging site and a production site open at once, a client's admin panel signed in under one address and a personal account under another, a chat window that has to stay reachable while the layout is being checked.

At that point the friction stops being about the toggle. It becomes about how many things are competing for one window and one signed in session. Separating the tools that are always open from the pages being inspected keeps the DevTools window free for actual work, and the way a set of persistent app windows can be switched as a named group is described in Workspaces. The behaviour of a browser that gives each service its own window and its own session is covered in Features.

What to set up first

If the goal is checking work, put Command+Option+I and Command+Shift+M into muscle memory and turn on Show media queries once, because it removes most of the guessing. If the goal is reading a site properly on a phone, set the per-site exception rather than the global default, so ordinary browsing stays on mobile layouts. A browser that keeps the tools you check with separate from the tools you work in is SpaceDeck, and the services it covers are listed in Supported apps.