How to test responsive design without a stack of phones
You don't need a drawer full of test phones to ship a solid mobile layout. You need a repeatable pass that catches the 90% of problems that are really layout problems, plus a short list of real-device checks for the rest.
Why a browser is enough for most of it
Responsive layout reacts to one thing: the CSS viewport — its width, its height, and orientation. Media queries, vw/vh units, container queries and flex/grid wrapping all key off those values. If you resize the viewport accurately and send a matching mobile User-Agent, you reproduce the layout a real phone renders. What you don't reproduce is touch behaviour, device pixel ratio, and platform browser quirks — worth checking, but a small slice.
A 4-step pass
1. Pick a device matrix, not "mobile"
Three widths cover most traffic: a small phone (~360px), a mainstream phone (~390–414px), and a large phone (~430px). Add one tablet (768–834px) if your product is used on iPads. Everything in between behaves like one of those.
2. Walk every breakpoint edge
Bugs cluster at the pixel where a layout switches. Drag the width slowly through each @media boundary and watch for text that reflows badly, images that overflow, and grids that jump from 2 columns to 1 with an awkward orphan.
3. Check both orientations
Landscape phone is the most-skipped viewport. Short height breaks sticky headers, full-screen modals and hero sections. Rotate every key page once.
4. Test with real content
Long names, missing images, a 3-line button label, an empty state. Placeholder content hides the layout failures users actually hit.
What still needs a real device
- Tap accuracy and scroll feel — hit targets, momentum scrolling, pull-to-refresh.
- DPR-sensitive rendering — hairline borders, sub-pixel text,
srcsetselection. - Platform quirks — iOS Safari's dynamic toolbar and
100vh, Android keyboard resize behaviour. - Performance — a mid-range Android is the honest benchmark, not your laptop throttled in DevTools.
Keep one cheap Android and one iPhone around for those. Simulate everything else.
Bake it into review
Add a preview link to every pull request that touches UI. A reviewer clicking viewonphone.com/?v=… and seeing the change at 390px wide is worth more than a screenshot, because they can poke at it.