To test responsive design properly, do three passes: sweep the viewport slowly from about 320 px to 1920 px wide to find where the layout breaks, check named devices with their real user agent and pixel ratio, and stress the layout with long content and 200% zoom. Most responsive bugs live between breakpoints and in content you did not design for, which is why checking three fixed sizes (“phone, tablet, desktop”) misses them.
Why checking three sizes is not enough
A layout is designed at a few widths, but it is used at all of them. A heading that fits at 375 px may wrap badly at 344 px (some foldable phones closed). A navigation bar that fits at 1024 px may overflow at 1100 px once a menu item gets longer. Bugs cluster:
- just below and above each breakpoint
- at widths no one designed for, such as 600–700 px (small tablets, split-screen windows)
- with real content that is longer than the design mockup
Pass 1: the width sweep
- Open Chrome DevTools, toggle the device toolbar (
Ctrl + Shift + M, orCmd + Shift + Mon a Mac) and choose Responsive. - Set the width to 320 px and drag the right edge slowly to the widest size you support.
- Watch for: horizontal scrollbars, text overlapping, buttons wrapping onto two lines, images stretching, grids leaving one orphaned card, and elements jumping as a breakpoint switches.
- When something breaks, note the exact width shown in the toolbar.
Turn on Show media queries in the device toolbar menu to see your breakpoints as coloured bars above the viewport. Clicking a bar jumps to that width. Step-by-step help for device mode is in the Chrome mobile emulator guide.
A useful habit: test each breakpoint at the exact value and one pixel below it. Off-by-one mistakes between max-width: 768px and min-width: 768px are common.
Pass 2: real device profiles
Width is only part of what a phone reports. Devices also send a mobile user agent, have a device pixel ratio of 2 or 3, and may trigger different server-side or JavaScript behaviour. Check your key pages on named profiles:
- a small phone (about 360–375 px wide)
- a current iPhone (393–402 px) and a large iPhone (430–440 px); values are in the iPhone viewport chart
- an Android phone (360–412 px)
- a tablet in both orientations (iPad and tablet guide)
DevTools device presets work for this. A responsive design tester extension such as Mobile View Extension is faster when you need to click through many pages: it reloads the tab with the device’s user agent, screen size and pixel ratio, keeps that device as you navigate, and lets you compare views of the same page side by side.
Pass 3: stress the content
Mockups use perfect content. Real sites do not. Try:
- Long words and strings: a long product name, a German translation, an email address or URL in a narrow column. Add
overflow-wrap: anywherewhere needed. - More or fewer items: a menu with eight items instead of five, a grid with seven cards instead of six.
- Missing images: what does the card look like when the image fails or is still loading?
- Large text: set the browser’s default font size to 20 px or more. Layouts built with
remshould scale; fixed-height boxes will clip text. - 200% and 400% zoom on desktop: zoom makes the CSS viewport narrower, so at 400% a 1280 px window behaves like a 320 px screen. WCAG 2.2 requires content to reflow without two-dimensional scrolling at that size, apart from content such as maps and data tables.
Pass 4: automate the screenshots
Manual passes find bugs once, and a mobile screenshot attached to a ticket shows the exact width where something broke. Automated screenshots catch them coming back. With a tool such as Playwright, a short script can open your key pages at, say, 360, 768, 1024 and 1440 px in Chromium, Firefox and WebKit, and compare screenshots against the previous version on every pull request. Visual regression testing like this is a good fit for design systems and marketing pages that change often.
Online responsive design checkers
Websites that show your URL in several frames at once are handy for a quick overview. They have limits: they load your page from their servers or in iframes, so they cannot reach localhost or pages behind a login, many sites block being framed, and the frames usually change width only, not the user agent. Use them for a glance, not for sign-off.
Responsive design testing checklist
| Check | How |
|---|---|
| No horizontal scroll at any width from 320 px | Width sweep |
| Breakpoints behave at exact value and value minus 1 px | Show media queries, type widths |
| Navigation works at every width | Width sweep + device profiles |
| Images sharp on 2x and 3x screens | Device profiles with pixel ratio |
| Content reflows at 400% zoom | Browser zoom on desktop |
| Long content does not break components | Content stress test |
| Same result in WebKit and Gecko | Safari or simulator, Firefox |
| No regressions after changes | Automated screenshots |
For the broader pre-launch checks beyond layout (forms, speed, SEO), use the mobile website testing checklist.
Frequently asked questions
How do I check the responsiveness of a website quickly?
Open Chrome DevTools, choose the Responsive mode in the device toolbar and drag the width from 320 px up. Anything that overflows or overlaps is a responsiveness bug.
What screen sizes should I test for responsive design?
Sweep all widths from 320 px, then check 360, 375, 390–402, 412 and 430–440 px for phones, about 768–834 px and 1024 px for tablets, and 1280–1920 px for desktop.
Is resizing the browser window a valid responsive test?
It is a valid test of CSS breakpoints, but desktop browsers stop shrinking at around 500 px and do not send a mobile user agent. Use device mode or a mobile view extension for phone widths.