How to test responsive design

Most responsive testing checks a list of phone names and misses the bugs entirely. The breakpoints that matter are the ones your own CSS declares — and four classes of bug never show up in device mode at all.

Updated September 2026 · by the Design Toolkit team

1. Find the real breakpoints

Testing "iPhone 15, iPad, Desktop" tests three arbitrary widths. Your layout does not change at those widths — it changes at the widths written in your stylesheet. Test those and you cover every device that will ever exist; test device names and you cover three of them.

Three ways to get the list:

2. Test either side of each one

Bugs live at the boundary. A grid that goes from three columns to one at 768px is fine at 900px and fine at 600px; the interesting widths are 767px and 768px, where a heading might suddenly wrap or a card might get 12px too narrow for its content.

So for each breakpoint, look at it twice — just below, just above. This is where a side-by-side viewer earns its place: both states on screen together, rather than resizing back and forth trying to remember what the last one looked like.

3. Check the two extremes

• 320px. Still the sensible floor. Anything narrower is rare enough to ignore; anything wider hides the overflow bugs that 320px exposes. Watch for long unbroken strings — URLs, email addresses, product codes — which force horizontal scroll on the whole page.
• Your widest. If your container has no max-width, check an ultrawide monitor: line lengths of 200 characters, and heroes where the text and the image drift apart.

A fast way to find overflow at any width: in the console, list anything wider than the viewport.

document.querySelectorAll('*').forEach(el => {
  if (el.getBoundingClientRect().right > document.documentElement.clientWidth)
    console.log(el);
});

4. The four bugs emulation cannot show you

Dynamic viewport height

On a phone, the address bar hides as you scroll, so the visible height changes while 100vh does not. A full-height hero is cut off at first load and leaves a gap once the bar hides. Use 100dvh, with 100vh before it as the fallback.

Sticky hover

There is no pointer to move away on a touch screen, so a tapped element keeps its hover state until something else is tapped. Cards that lift on hover stay lifted; buttons stay highlighted. The fix is to make hover styles conditional:

@media (hover: hover) {
  .card:hover { transform: translateY(-4px); }
}

Font fallback

A typeface installed on your machine renders locally and falls back on a device that does not have it — with different metrics, so a heading that fit on one line now takes two. Test with local fonts disabled, or check on hardware. If you rely on a system font stack, know what each platform will actually pick.

Which image gets chosen

A phone at a device pixel ratio of 3 requests a much larger file from your srcset than your desktop does. Set the DPR in device mode and watch the Network panel to confirm the right file is being served, not the 2400px one over a mobile connection.

The checklist

• Every declared breakpoint, one pixel either side
• 320px, with no horizontal scroll anywhere
• Your widest supported width
• Tap targets at least 44×44px, with space between them
• Hover styles behind @media (hover: hover)
• dvh instead of vh for full-height sections
• Tables and code blocks scrolling inside their own container, not the page
• Text still passing contrast over any image that reflows
• One pass on a real phone, throttled to a slow connection

Common questions

Read next