Responsive testing has a scope problem. There are thousands of device and browser combinations in the wild, you can’t test all of them, and pretending you can is how teams end up doing nothing systematic at all.
The good news: you don’t need all of them. You need a small, deliberate matrix of viewports, a fast way to check it on every change, and a clear idea of when an emulator is good enough versus when you need real hardware. That’s what this guide covers.
One disclosure up front: I build Hoverify, a browser extension whose Responsive tool does multi-device testing. It shows up in the tooling section below, alongside free and non-affiliated alternatives.
What responsive testing actually covers
“Does it look okay on mobile” is only a third of the job. A useful test pass checks three things at every size:
- Layout — does content scale, wrap, and reflow without overlapping, clipping, or overflowing the viewport?
- Function — do menus, forms, carousels, and modals actually work with touch input and an on-screen keyboard, not just with a mouse?
- Performance — does the page stay usable on the slower CPUs and networks that real phones have?
Concretely, the areas where responsive bugs cluster:
| Area | What to check |
|---|---|
| Navigation | Menu collapse behavior, dropdowns fitting on screen, tap targets big enough to hit |
| Forms | Input types (tel, email, number), on-screen keyboard not covering fields, autocomplete |
| Media | Images scaling without distortion, video playback, aspect ratios holding |
| Typography | Readable sizes (16px minimum body text on mobile), line lengths, wrapping |
| Interactive elements | Hover-only interactions having touch equivalents, spacing between targets |
Most responsive bugs hide in forms, navigation, and third-party embeds — exactly the places a quick visual scan of a resized homepage misses. Test real flows: search, add to cart, checkout, sign-up.
First, understand what a “pixel” means
This trips up more developers than any breakpoint ever will. The pixels in your CSS are not the pixels on the screen.
- Physical pixels are the actual dots on the display.
- CSS pixels are the units your stylesheets use.
- Device pixel ratio (DPR) is the ratio between them.
An iPhone 15 has a 1179×2556 physical display, but its DPR is 3, so your CSS sees a 393×852 viewport. Most modern Android phones report CSS widths in the 360–412px range regardless of how many physical pixels they pack.
Three practical consequences:
- Design and test in CSS pixels. A “1080p phone” is a ~400px-wide layout problem, not a 1080px one.
- Ship higher-resolution images for high-DPR screens with
srcset(small.jpg 1x, large.jpg 2x), or use SVG where you can — it stays sharp at every density. - A 1px hairline border can render inconsistently across DPRs. If a border looks fine on your monitor and blurry on a phone, DPR is usually why.
Pick your viewport matrix
You need to decide which sizes you’re committing to test on every change. Your analytics are the best source — check the actual screen sizes your visitors use. Absent that data, this matrix covers the common ground:
| Range (CSS px) | Represents | Example test width |
|---|---|---|
| 320–479 | Small phones | 360 |
| 480–767 | Large phones | 393 (iPhone 15) or 412 |
| 768–991 | Tablets portrait | 768 |
| 992–1199 | Tablets landscape, small laptops | 1024 |
| 1200–1439 | Laptops | 1366 |
| 1440+ | Desktops | 1920 |
Two things matter more than the exact numbers. First, your breakpoints should come from where your layout breaks, not from a device list — we go deeper on that in the responsive breakpoints guide. Second, test between the breakpoints too: the widths just before a media query kicks in are where squeezed layouts hide.
The testing ladder: DevTools → extension → real devices → device cloud
There are four tiers of responsive testing, in increasing order of fidelity and cost. Use the cheapest tier that can catch the bug you’re looking for.
Tier 1: Browser DevTools (free, always available)
Chrome’s device toolbar simulates viewport sizes, DPR, touch events, and network throttling. It’s the right tool for quick spot checks while writing CSS, and it’s built in. Open DevTools, toggle the device toolbar, pick a preset or type custom dimensions. We have a full walkthrough in how to use responsive design mode in Chrome.
Its limitation is workflow: one viewport at a time. Checking six breakpoints means dragging a handle back and forth six times per change, and it’s easy to skip that on the tenth edit of the day.
Tier 2: A multi-device extension (fast iteration)
This is where Hoverify’s Responsive Viewer sits. It renders your site on multiple devices at once in a single window — click a link on one device and every device follows; scroll one and they all scroll; since the 4.8 update, form inputs sync too, so you can type into a checkout field once and watch the layout hold up (or not) on every screen simultaneously.
Details that came out of real testing pain:
- The device roster stays current (iPhone 15 and 16 lineups, Pixel 7 Pro, Nothing Phone), and you can define custom profiles for anything else.
- It can inject itself directly into the page instead of relying on iframes. Purely iframe-based testers fail on sites that send
X-Frame-Optionsor frame-blocking CSP headers — which includes a lot of production sites. Injection mode opens those anyway, and it strips the headers that give away device emulation, so sites that serve different markup to mobile visitors behave the way they actually would on a phone. - Each device’s viewport can be captured as a screenshot, with optional device frames, which is handy for client sign-off.
- When a breakpoint looks wrong, the Inspector is in the same extension: hover the element, see its CSS and media queries, edit live, and re-check every device in one view. That loop is the whole point — there’s a walkthrough in debugging responsive design issues in under 5 minutes.
Hoverify is paid — $30/year (or $89 lifetime) for three browsers, 14-day refund, no free trial. If you only need synced scrolling on a couple of viewports, free alternatives exist; we compare them honestly in 5 Chrome extensions for responsive testing.
Tier 3: Real devices (the truth)
Emulation can’t fully reproduce touch physics, real on-screen keyboards, browser chrome eating viewport height (mobile Safari’s collapsing URL bar has broken more 100vh layouts than any other single cause), thermal throttling, or genuine mobile GPU rendering.
You don’t need a drawer full of phones. One current iPhone and one mid-range Android cover the two engines and OSes that matter, because on iOS every browser uses WebKit. Test the flows that make you money on those two devices before every significant release.
Tier 4: A cloud device lab (breadth on demand)
Services like BrowserStack and LambdaTest stream real devices to your browser — useful when a bug report comes in from a device you don’t own, or when you need to verify a fix on an old Android build.
| Cloud device lab | Your own devices | |
|---|---|---|
| Setup cost | Subscription | Hardware purchase |
| Device breadth | Thousands of combinations | A handful |
| Access | Anywhere, instantly | Physically present |
| Fidelity | Real hardware, but streamed | Full — it’s in your hand |
| Best for | Reproducing device-specific reports | Routine pre-release checks |
For most sites the honest answer is: tiers 1–3 for daily work, tier 4 on demand.
Test both orientations
Orientation is the most-skipped part of responsive testing, and it’s not optional: WCAG 2.1’s Orientation criterion (1.3.4, Level AA) requires that content work in both portrait and landscape unless a specific orientation is essential.
What to check:
- Rotate mid-flow, not just on the homepage. Fill half a form in portrait, rotate, and confirm nothing is lost and the keyboard doesn’t cover the active field.
- Landscape on phones is short. A 393×852 portrait viewport becomes 852×393 — sticky headers and cookie banners can eat most of those 393 pixels. Check that content is still reachable.
- Fixed elements (chat widgets, floating CTAs) are the most common landscape casualties.
DevTools and Hoverify’s Responsive tool can both flip orientation per device; real-device rotation catches the keyboard and scroll-position issues emulators miss.
Test under real network and CPU conditions
Your dev machine on office Wi-Fi is the best-case scenario your users will never see. Chrome DevTools can throttle both network and CPU; run your key pages with throttling on and watch what happens to images, fonts, and third-party scripts.
Focus on the Core Web Vitals as user-experienced metrics:
- LCP (Largest Contentful Paint) — when the main content actually appears.
- CLS (Cumulative Layout Shift) — whether the layout jumps around while loading. Unsized images and late-loading embeds are the usual offenders, and they hurt most on small screens.
- INP (Interaction to Next Paint) — responsiveness to taps and clicks. INP replaced First Input Delay as a Core Web Vital in 2024, so ignore older checklists that still say FID.
The standard fixes are well-known and effective: properly sized srcset images, loading="lazy" below the fold, explicit width/height (or aspect-ratio) on media to prevent shift, and a hard look at every third-party script.
Accessibility is part of responsive testing
Small screens amplify accessibility problems: touch targets shrink, contrast suffers in sunlight, and zoomed text overflows containers that were sized in pixels.
- Touch targets: Apple’s guideline is 44×44pt; WCAG 2.2 sets a 24px minimum (2.5.8, AA). Check spacing between adjacent targets, not just size.
- Zoom: text must survive 200% zoom without loss of content (WCAG 1.4.4), which in practice means relative units (
rem/em) and containers that grow. - Keyboard and screen reader: mobile menus that only open on touch events are invisible to some assistive tech. Test with keyboard navigation at desktop sizes and VoiceOver/TalkBack on real devices.
Hoverify’s SEO tool includes a WCAG accessibility audit (with suggested contrast fixes and a PDF export) if you want a structured starting point, and free options like WAVE and axe cover automated checks well.
Manual vs automated testing
Both have a place, and the trade-offs are straightforward:
| Manual testing | Automated testing | |
|---|---|---|
| Catches | Subtle UX issues, “feels wrong” problems | Regressions in things that used to work |
| Speed | Slow, doesn’t scale | Fast, runs on every commit |
| Cost curve | Cheap to start, expensive forever | Expensive to start, cheap forever |
| Blind spots | Inconsistent, skips steps under deadline | Only finds what it’s told to look for |
A practical division of labor: automate viewport screenshots of your key pages at your matrix widths (visual regression tools like Playwright’s screenshot testing make this cheap) and let CI flag diffs on every commit. Keep humans on exploratory testing — rotating devices mid-flow, mashing the keyboard into forms, testing with one thumb on an actual phone.
If you set up only one automated check, make it this: screenshot your top three pages at 360, 768, and 1366 on every deploy, and diff against the previous build. It catches the “someone’s CSS change broke tablet” class of bug for nearly zero ongoing effort.
A repeatable checklist
For every significant change:
- Check your viewport matrix in a multi-device view (or step through it in DevTools).
- Run the affected user flow — not just the page — at mobile and desktop sizes.
- Rotate once, mid-flow.
- Throttle once, on your heaviest page.
Before every release, add:
- Real-device pass on one iPhone and one Android for money flows.
- Visual regression diff on key pages.
- Zoom to 200% and tab through the page.
Responsive testing isn’t a project you finish; it’s a loop you make cheap enough to run every day. That’s the actual reason I built the Responsive tool into Hoverify — not because emulators are wrong, but because a check you can do in one window on every save is a check that actually happens.
