Viewpo
How to test responsive design: 6 methods compared
From browser resize to automated CI/CD checks — every way to test if your site works across screen sizes, with trade-offs for each.
Responsive design testing is how you verify that a website works well across different screen sizes — phones, tablets, laptops, and desktops. In 2026, over 60% of web traffic comes from mobile devices, but most developers still build and test on laptops. The gap between what you see during development and what your visitors experience on their phones is where responsive bugs hide. This guide covers six methods for testing responsive design, from the simplest (resizing your browser) to the most automated (CI/CD pipeline checks). Each method has different trade-offs between speed, accuracy, and effort. Most teams use a combination.
1. Browser window resize
The simplest test: grab the edge of your browser window and drag it narrower. You'll see your layout reflow in real time, and obvious issues — text overlapping, images overflowing, navigation breaking — are immediately visible. It's free, instant, and requires no tools. The downsides: you only see one width at a time, there's no record of what you tested, and you're relying on your own eyes to catch problems. You won't notice subtle issues like touch targets that are technically too small, or elements that are 1 pixel wider than the viewport. Browser resize is a good first sanity check, but it's not a complete responsive test.
Hold Ctrl+Shift+M (Cmd+Shift+M on Mac) in Firefox to toggle responsive design mode — it shows a viewport size selector at the top of the page.
2. Chrome DevTools device mode
Chrome DevTools includes a device emulation mode (toggle it with Ctrl+Shift+M or the device icon in DevTools). It lets you select from preset device sizes — iPhone SE, iPad, Galaxy S series — or enter custom dimensions. You can also throttle CPU and network to simulate real mobile conditions. DevTools is more precise than browser resize because you see the exact pixel width, can test specific devices, and can throttle performance. But it still shows one viewport at a time, doesn't detect issues automatically, and requires you to manually check each breakpoint. It's the go-to tool for debugging a specific responsive issue you've already found, but less efficient for catching issues you don't know about.
In DevTools device mode, click "Show media queries" in the viewport bar to see exactly where your CSS breakpoints trigger.
3. Web-based responsive testing tools
Web-based tools let you paste a URL and see it rendered at multiple screen sizes simultaneously. This category includes iframe-based tools (responsivedesignchecker.com, Screenfly) and real-browser tools (Viewpo). Iframe-based tools embed your site in iframes at different widths. They're fast but break on most modern sites — any site with X-Frame-Options or Content-Security-Policy headers (which is most of them) will show a blank page or error. Real-browser tools like Viewpo render your site in an actual Chromium browser and take screenshots, so they work on every site regardless of security headers. The best tools in this category also run automated checks — overflow detection, touch target sizing, contrast — so you get specific issues to fix, not just visual previews.
Viewpo shows your site at phone (375px), tablet (820px), laptop (1440px), and desktop (1920px) simultaneously, with A-F grading and automated issue detection. Free for 50 audits per month.
4. Desktop responsive testing apps
Desktop applications like Polypane, Responsively App, and Sizzy show multiple viewports side by side during development. They offer features web-based tools can't: synced scrolling across viewports, live CSS editing, and real-time preview as you code. Polypane ($14/mo) is the most polished, with built-in accessibility checks and focus order visualisation. Responsively App is free and open source but requires installation. These tools are designed for active development — you keep them open alongside your code editor and test as you build. The trade-off: they require installation, they're local-only (can't share results with a link), and they don't work for testing deployed sites in CI/CD. They're best for developers who test responsiveness daily during development.
5. Real device testing
Emulators and simulators approximate how a device renders, but nothing beats testing on the actual hardware. Real device testing catches issues that emulators miss: how text renders at actual DPI, whether touch targets feel right under a thumb, how the site performs on a lower-powered mobile processor, and how it looks on specific screen technologies (OLED blacks, LCD colour shifts). You don't need a wall of devices. Start with the devices your analytics show are most popular — typically the latest iPhone, a mid-range Android phone (Samsung Galaxy A series), and an iPad. BrowserStack and LambdaTest offer cloud access to real devices, but they're expensive ($29-99/mo) and slower than local testing. For most teams, two physical devices plus emulator testing covers 90% of issues.
Check your analytics to find the top 5 devices your visitors actually use. Test on those first — not on the latest flagship.
6. Automated testing in CI/CD
The most thorough approach: run responsive checks automatically every time code is deployed. Viewpo's HTTP API returns structured JSON with screenshots and audit results, making it straightforward to add responsive checks to GitHub Actions, GitLab CI, or any pipeline. Visual regression tools like Percy and Applitools compare screenshots between deploys to catch unintended layout changes. Playwright and Cypress can run viewport-specific tests that check for specific elements at each breakpoint. The value of automated testing is consistency — it catches regressions that manual testing misses because humans get tired and skip steps. The cost is setup time and (for some tools) ongoing subscription fees. Start with a simple "does the site render without horizontal scroll at 375px?" check and expand from there.
A minimal CI responsive check: use Viewpo's API to audit your staging URL after deploy. If the grade drops below B, fail the build.
Which method should you use?
Most teams benefit from a combination. During development, use Chrome DevTools device mode to test at specific breakpoints as you code. Before merging, use a web-based tool like Viewpo to get a comprehensive multi-viewport audit with automated issue detection — this catches things you missed in DevTools. For critical flows (checkout, signup, onboarding), test on 2-3 real devices your users actually use. For production monitoring, add automated responsive checks to your CI/CD pipeline so regressions don't slip through. The goal isn't to use every method on every change. It's to match the testing effort to the risk: a copy change needs a quick browser resize, a new page layout needs DevTools plus a Viewpo audit, and a redesign needs the full stack including real device testing.
Frequently Asked Questions
Common questions about how to test responsive design.
The simplest approach is resizing your browser window and checking for layout issues. In Chrome, press F12 to open DevTools, then Ctrl+Shift+M (Cmd+Shift+M on Mac) to enter device mode. You can select preset device sizes or enter custom dimensions. This won't catch everything — you'll miss automated checks for overflow, touch targets, and contrast — but it's a good starting point.
Try Viewpo free — no install required
Paste any URL and get real browser screenshots at multiple viewports with an A-F responsive design grade. 50 free audits per month.
Free during beta. Plans from $19/mo at launch — early supporters get a lifetime discount.