Responsive design testing has a scale problem. A site with 200 pages and eight breakpoints is 1,600 layouts, and every one of them can break independently: a table that overflows only at 768px, a hero image that stretches only at 1440px, a mobile menu that stopped opening after a plugin update. Nobody checks 1,600 layouts by dragging a browser window, so in practice teams check the homepage on their phone and ship.
This guide is the version of that process that scales. It covers which breakpoints are actually worth testing in 2026 and why, what to look for at each one, where manual testing still earns its place, which tools do what, and how to turn the whole thing into an automated check that runs on every deploy.
Which breakpoints matter in 2026
Start with what people actually use. StatCounter’s worldwide data for August 2026 splits traffic almost evenly: mobile 49.4%, desktop 49.1%, tablet 1.5%. The most common reported screen widths tell you where the mass is:
- Phones: 414×896 (13.6% of mobile), 360×800 (9.3%), 390×844 (6.8%), 393×873 (5.3%). Almost every phone in the top ten reports a width between 360 and 430 CSS pixels.
- Tablets: 768×1024 is the single most common tablet size, with 800×1280 and 1280×800 close behind.
- Desktops: 1920×1080 alone is 22% of desktop traffic. 1536×864 (a 1920 display at 125% scaling) and 1366×768 are the other large clusters.
Two things follow from this. First, the widths CSS sees on phones are small — 360 to 430 pixels — regardless of how many physical pixels the screen has. A media query at max-width: 480px is a phone query; one at 600px is not. Second, the desktop range is wide. 1366 and 1920 are both common, and a layout that looks fine at one can leave a lot of empty space or a cramped grid at the other.
There is also a lower bound worth keeping. WCAG 2.1 success criterion 1.4.10 (Reflow) requires content to work at a 320 CSS-pixel width without horizontal scrolling. It is the width of the smallest iPhones ever sold and of a 1280px desktop window zoomed to 400%, which is how some low-vision users browse. If you test one narrow width, make it 320.
The checklist of breakpoints to test
The best breakpoints to test are the ones your CSS actually switches at, plus the device widths above. If you use a framework, the framework’s defaults are the switch points:
- Tailwind CSS: 640, 768, 1024, 1280, 1536
- Bootstrap 5: 576, 768, 992, 1200, 1400
Diffy’s ten preset breakpoints line up with both lists and with the device clusters: 320, 640, 720, 768, 960, 1024, 1080, 1200, 1440, 1920. A new project starts with three of them selected (640, 1024, 1200), and you can add any custom width between 240 and 2000 pixels — a 375 for the older iPhone viewport, a 1366 for the laptop cluster, a 1536 for scaled 1080p displays.
A practical set for most marketing and content sites is six widths:
| Width | Why it is on the list |
|---|---|
| 320 | WCAG reflow minimum; smallest phones; catches every overflow bug |
| 375 or 390 | Typical iPhone viewport; the mobile layout most visitors see |
| 768 | Tablet portrait; the md breakpoint in Tailwind and Bootstrap; the width most sites collapse the menu at |
| 1024 | Tablet landscape / small laptop; lg in Tailwind |
| 1366 or 1440 | Laptop; the width designers usually hand over |
| 1920 | Full HD desktop; the most common desktop resolution |
Add 640 if you use Tailwind (it is the sm switch), 992 or 1200 if you use Bootstrap, and 1536 or 2000 if your design has a max-width container that stops growing — the interesting question at very wide screens is whether the background, header and footer keep behaving once the content stops.
One more rule: test just inside a breakpoint, not only at it. A menu that collapses at max-width: 767px is fine at 768 and broken at 767. If your CSS switches at 768, screenshot 767 or 760 as well. Custom breakpoints exist for exactly this.
What breaks at each breakpoint
Responsive regressions are repetitive. The same dozen problems account for most of what a screenshot run finds:
Horizontal overflow. A fixed-width element (a table, a code block, an embedded iframe, an image with an explicit width) is wider than the viewport, and the whole page gains a horizontal scrollbar. Common at 320–414, almost always caused by content an editor added rather than by the theme.
Navigation. The hamburger menu does not open, opens behind the hero, or the desktop menu wraps onto two lines at 1024 because someone added a seventh item. Menus need to be tested open as well as closed — Diffy can run a click before taking the screenshot, which is how you capture tabs, mobile menus and sliders in their active state.
Images and media. Hero images cropped to a strip on mobile, object-fit missing so a portrait image is squashed, srcset serving the desktop image to a 360px phone, or a video embed with a fixed height that leaves a black bar at 1920.
Typography and spacing. Headings that wrap to five lines at 320, or a 16px body size that looks like a footnote on a 1920 display. Fluid typography (clamp()) fixes the second problem and creates a new class of bugs where text is a different size at every width and no single screenshot looks wrong.
Grids and cards. A three-column card grid that becomes one orphaned card on a second row at 1024, or cards of different heights because one title wrapped and the others did not.
Tables and forms. Tables that need horizontal scrolling on their own (fine) versus tables that make the page scroll (not fine). Forms where labels and inputs lose their association when they stack, and buttons that fall below the fold on a 320×568 viewport.
Sticky and fixed elements. A sticky header that covers the first heading on mobile, a cookie banner that takes 40% of a phone screen, a chat widget that sits on top of the primary button at 375.
Hidden content. Things that are display: none at one width and forgotten: the desktop-only sidebar that contained the only link to a page, or the mobile-only phone number that also shows on desktop after a CSS refactor.
Most of these are not visible in one breakpoint’s screenshot. They appear as differences between breakpoints, which is why testing a range matters more than testing any single width perfectly.
Manual vs automated responsive testing
Both have a job. The mistake is using one for the other’s job.
Manual testing is for judgement: does the mobile layout feel right, is the tap target big enough, does the animation stutter on a mid-range Android phone, does the page still work with a screen reader. Chrome DevTools’ device mode is the quickest way to look at a page at any width, and its own documentation is clear about the limits — “think of device mode as a first-order approximation of how your page looks and feels on a mobile device.” For anything that depends on real hardware — touch, performance, iOS Safari quirks, the address bar collapsing — a real device or a device cloud is the only honest test.
Automated testing is for coverage and repetition: every URL at every width, after every change, compared with the last known-good version. A person cannot re-check 1,600 layouts after a dependency update; a script can, and a visual comparison tells you which of the 1,600 changed so a person only looks at those.
The dividing line is simple. Use people to decide whether a layout is good. Use automation to find out whether a layout changed.
Tools for responsive testing
Grouped by what they are for, with the honest caveats:
Browser dev tools (free). Chrome DevTools device mode, Firefox Responsive Design Mode and Safari’s Responsive Design Mode all resize the viewport and emulate common device profiles. They are the right tool for fixing a layout at a specific width. They test one page at one width at a time, and they are still your laptop’s rendering engine, not a phone’s.
Multi-viewport browsers. Responsively App is free and open source: it shows the same page in several device frames side by side, mirrors scrolling and clicks across them, and takes screenshots of all of them at once. Polypane is a paid browser (14-day trial) built for the same job, with accessibility and SEO checks layered on. Both are development tools — good while you are building, not a substitute for testing after deploy.
Real-device clouds. BrowserStack and LambdaTest give you real phones and tablets in a browser tab, and BrowserStack’s responsive checker renders a URL across a set of iOS and Android devices. This is where you test iOS Safari behaviour, touch, and anything that emulation gets wrong. They are paid products (BrowserStack’s free plan caps the responsive checker at 100 tests), and the checker is a spot check, not a regression suite.
Test frameworks. Playwright and Cypress can set the viewport per test and Playwright ships device descriptors (viewport, user agent, device scale factor and touch) for common phones. If you already have end-to-end tests, running the important ones at a mobile viewport is cheap and catches functional breakage — a menu that does not open — but a passing test says nothing about how the page looks.
Visual regression testing. This is the category Diffy is in. The tool takes a screenshot of every page at every breakpoint, stores it as a baseline, and after each change takes a new set and highlights the pixels that differ. It does not know what the page should look like; it knows what it looked like last time, which turns out to be the question you actually have after a theme update, a plugin upgrade, or a CSS refactor.
Automating it: every breakpoint, every URL, every deploy
Here is what the automated version of responsive testing looks like in Diffy, end to end.
1. Build the page list. Point the project scan at your sitemap or homepage and it extracts the URLs. Keep the pages that represent each template — one article, one product, one landing page — plus everything in the main navigation. You do not need all 4,000 tag pages to know whether the tag template is fine.
2. Pick the breakpoints. Tick the presets you want and add custom widths for your framework’s switch points and the just-inside values (767, 1023). Six to eight widths is typical. The cost is linear: one full-page screenshot per URL per breakpoint, in Chrome or WebKit, so 50 pages at eight widths is 400 screenshots per run. The free plan includes 500.
3. Stabilise the pages. Freeze carousels, hide the cookie banner, mock the dates and dynamic content. The false-positives guide covers the settings; they take ten minutes once and save an hour on every run. If the site serves different markup to phones based on the user agent, set a mobile User-Agent header in the project so the narrow screenshots get the mobile markup rather than desktop markup squeezed into 375 pixels.
4. Take the baseline. Run the screenshots against production and approve the set. This is your “known good” at every width.
5. Compare on every change. Run the same set against staging, a pull-request preview, or production after deploy, and compare it with the baseline. From CI this is one CLI command; there are ready-made setups for GitHub Actions, GitLab, Pantheon, Tugboat and Platform.sh. If you deploy from a CMS without a pipeline, scheduled monitoring takes a fresh set on the days you choose and compares it with the previous one.
6. Review by exception. The comparison groups results by breakpoint, so you can look at all the 320px diffs together, and a change that appears on many pages — a footer edit that shifted every page at every width — can be approved once across all of them. The AI summary lists what changed with the URLs and breakpoints affected, so a run over 400 screenshots reads as a short list rather than a wall of red. Diffy’s default comparison algorithm also ignores content that merely shifted down the page, which matters on responsive layouts where a taller header at 768 pushes everything below it.
What this does not cover, and what still needs a person or a device cloud: touch interactions, scroll performance, real iOS Safari rendering, and whether the layout is any good in the first place. Diffy resizes a real Chrome or WebKit engine to the width you ask for; it does not run your page on a phone. For most responsive regressions — overflow, broken menus, stretched images, collapsed grids — a width change in a real engine is exactly the test you need, and the one nobody was doing by hand.
Frequently asked questions
How many breakpoints should I test? Enough to hit each layout your CSS produces, plus the device clusters: usually five to eight. Testing 20 widths mostly produces 20 copies of the same layout. If a page looks the same at 1440 and 1920, keep 1920 (it is the more common device) and drop the other.
Should I test at device widths or at my CSS breakpoints? Both, and one pixel inside each CSS breakpoint. Device widths tell you what visitors see; CSS breakpoints tell you where the layout changes; the just-inside width (767 for a 768 breakpoint) is where the “wrong side” bugs live.
Does resizing a desktop browser count as mobile testing? For layout, yes — it is the same media queries and the same reflow. For behaviour, no. Touch, hover states that stick on touch screens, the iOS address bar, font rendering and performance all need a real device. Use screenshots for coverage and a real phone for judgement.
Which breakpoints does Diffy support? Ten presets (320, 640, 720, 768, 960, 1024, 1080, 1200, 1440, 1920) and any custom width from 240 to 2000 pixels. Screenshots are full page, taken with a Chrome or WebKit engine, one per URL per breakpoint.
How do I test a mobile menu, not just the closed page? Run a click action before the screenshot. Diffy lets you execute JavaScript on the page before capture, so you can open the menu, switch a tab or advance a slider and screenshot that state at every breakpoint. The tabs, menus and sliders guide walks through it.
Is this different for a site migration or redesign? The breakpoint list is the same; the comparison changes. On a migration you compare the old site with the new one at every width instead of comparing the new site with itself over time. The website migration testing checklist covers that workflow.
If you want to see what your site looks like at all ten widths right now, create a free project, scan your sitemap, and run one screenshot set. The 500 free screenshots cover about 60 pages at eight breakpoints, which is more responsive testing than most sites have ever had.