How to Test Responsive Design Across Different Screen Sizes

Most responsive bugs don't live at 375px or 1440px. They live in the space between your breakpoints, where nobody looks. Testing three device presets and calling it done is why so many sites break at 900px wide.

Here's a method that catches more, in roughly the order you should do it.

Start by dragging, not by choosing a device

Open DevTools, press Ctrl+Shift+M (Cmd+Shift+M) to toggle device mode, and set the dropdown to Responsive rather than a named device. Then drag the right edge of the viewport slowly from 320px up to 1600px and watch.

You're looking for four things:

• The moment a layout stops fitting and starts overflowing
• Text that reflows into an awkward orphan or a two-word line
• Images that stretch, crop badly, or suddenly change aspect ratio
• Elements that overlap for a narrow band of widths and then recover

That last one is the category everyone misses, because it only exists in a 40px window that no preset lands on.

Know your own breakpoints

You can't test breakpoints you can't name. On a codebase you didn't write, or one that's accumulated a few years of media queries, extracting the real list is the first job.

Three tools in Web Developer Tools do this for you: CSS Media Query Viewer lists every media query the document actually loaded, Responsive Breakpoint Viewer visualises them, and View Media Query Info turns the same information into a searchable report. Reading that list usually turns up two or three breakpoints nobody remembered adding, often within a few pixels of each other.

Chrome shows breakpoint markers in device mode too: click the three-dot menu in the device toolbar and enable Show media queries. The coloured bars above the ruler are clickable, which is a fast way to jump between them.

What device emulation gets wrong

Device mode changes viewport size, device pixel ratio, user agent string and touch event simulation. It does not change the rendering engine, the available fonts, the way the on-screen keyboard resizes the viewport, or how iOS Safari handles 100vh.

So it's excellent for layout and useless for a certain class of bug:

Emulate for the first pass. Confirm anything important on a real device, or at least on a real Safari if you're on a Mac.

The viewport meta tag

If your mobile layout looks like a shrunken desktop, this is almost always why:

<meta name="viewport" content="width=device-width, initial-scale=1">

Without it, mobile browsers assume a ~980px viewport and scale everything down. And avoid maximum-scale=1 or user-scalable=no: they block pinch zoom, which is an accessibility failure under WCAG 1.4.4.

Viewport Meta Viewer shows the parsed tag and Missing Viewport Meta Detector flags its absence. Both are worth running on any page rendered by a template you didn't write, since it's easy for one route to miss it.

Finding horizontal overflow

Horizontal scroll on mobile is the single most common responsive defect, and it's caused by one element being wider than its container. The usual suspects: a table, a <pre> block, an image without max-width: 100%, a fixed pixel width, a long URL in body text, or a negative margin.

img, video, canvas, svg { max-width: 100%; height: auto; }
pre, code { overflow-x: auto; }
* { min-width: 0; }  /* stops flex children refusing to shrink */

To find an existing one, the Overflow Detector highlights the elements causing horizontal scroll rather than making you bisect the DOM by hand. Run Fixed Width Layout Detector afterwards: hardcoded pixel widths are where the next overflow is going to come from.

Touch targets and spacing

The WCAG 2.2 target size minimum is 24×24 CSS pixels; both Apple and Google recommend closer to 44–48px. Icon buttons in a dense header are the usual offenders, especially when someone reduced their padding to fit a narrow viewport.

Measure rather than eyeball it. A Touch Target Size Checker flags tap targets under 48px across the whole page, which beats inspecting each button and reading the box model.

Images at different densities

A layout that works at every width can still ship a 2400px hero to a 360px phone. Check that responsive images are actually responsive:

• srcset and sizes present on anything large, with sizes reflecting the real rendered width rather than 100vw everywhere
• <picture> used where the art direction genuinely changes between breakpoints
• width and height attributes on every <img> so the browser can reserve space and avoid layout shift
• loading="lazy" on below-the-fold images, and specifically not on the LCP image

View srcset Attributes, Responsive Image Audit and Missing Width/Height Attributes cover all four directly. There's more on this in the guide to analysing images on a page.

Orientation, notches and the parts people forget

Landscape on a phone is a short, wide viewport, and it's where fixed headers plus a modal frequently leave no room for content. Rotate and check anything with a sticky element.

Safe areas matter too. On notched devices, content in the top or bottom inset needs env(safe-area-inset-*) padding, or it sits under the notch or the home indicator. WDT includes an Orientation Simulator and a Device Safe Area Simulator for exactly this pass.

Seeing several sizes at once

Dragging a viewport shows you one width at a time. When you're checking a change across the whole range, seeing several rendered simultaneously is quicker and makes inconsistencies obvious. WDT's View Responsive Layouts previews the page at multiple device sizes side by side; Resize Window snaps the actual browser window to a preset, which is the more honest test because it uses the real window rather than an emulated one.

A checklist you can run in ten minutes

1. 1Confirm the viewport meta tag is present and doesn't block zoom
2. 2Drag from 320px to 1600px and note every width where something breaks
3. 3Test one pixel either side of each of your own breakpoints
4. 4Check for horizontal overflow at 320px and 360px
5. 5Rotate to landscape on a phone-sized viewport
6. 6Zoom the browser to 200% and check nothing is cut off
7. 7Tab through the page at mobile width to confirm focus order still makes sense
8. 8Check tap target sizes in any dense navigation
9. 9Confirm images have width, height and sensible srcset
10. 10Load it on one real phone before you ship

Browser zoom deserves a mention on its own. Zooming to 200% is roughly equivalent to halving the viewport width, and it's a WCAG requirement, but it exercises different code paths than resizing does. Sites that pass a width test sometimes fail a zoom test.

When the layout breaks and you need to work out which rule is responsible, the CSS debugging guide picks up where this leaves off. For the browser-side shortcuts that make this loop faster, see the DevTools tips.