A practical strategy for testing websites across screen sizes — which breakpoints matter, what bugs to look for, and how to test efficiently.
Most responsive testing advice stops at "check your site on a phone". That is not wrong — but it leaves out the why, the what, and the how. Without a systematic approach you end up with blind spots: layouts that look fine on your iPhone but break on a 768px tablet, or a desktop design that falls apart at 1024px on a small laptop.
This guide gives you a concrete testing strategy: the specific viewport widths to check, the exact layout problems to look for at each one, and a checklist you can run on any project before shipping.
Testing every conceivable screen width is impractical. Instead, focus on the widths that represent real user populations and the boundaries where layouts are most likely to break.
These are the most common classes of responsive bug. Work through each category systematically rather than eyeballing pages at random.
These are the bugs that appear repeatedly across projects. Understanding why they happen makes them faster to diagnose and fix.
Setting width: 100vw on a full-bleed section adds the scrollbar width to the element width, causing horizontal overflow. Use width: 100% on block elements instead.
Flex children have an implicit min-width: auto, meaning they will not shrink below their content size. Add min-width: 0 to flex children that should shrink.
An absolutely positioned element without a positioned ancestor climbs the DOM to the viewport, causing overflow at specific widths where it lands outside the expected container.
grid-template-columns: repeat(3, 1fr) does not wrap. At 768px it forces three narrow columns. Use auto-fill with minmax instead: repeat(auto-fill, minmax(240px, 1fr)).
Images inside flex rows stretch to fill the row height when align-items: stretch is in effect (the default). Set align-items: flex-start or add align-self: flex-start to the image.
height: 100vh includes the browser toolbar on mobile, causing the bottom of full-screen sections to be hidden. Use the dvh unit (100dvh) or JS-based viewport height measurement.
Input elements with font-size below 16px cause iOS Safari to zoom the page on focus. Always set font-size: 16px or larger on inputs, or add font-size: max(16px, 1rem).
A fixed header with z-index: 100 can be visually overlapped by a child element in a section that creates its own stacking context (transform, opacity, filter). Often only visible at certain scroll positions on mobile.
Run this at every major breakpoint (375px, 768px, 1280px, 1920px) before shipping any page. Each step targets a specific class of bug that visual inspection alone misses.
At every breakpoint: is there an x-axis scrollbar? If yes, open DevTools and run: Array.from(document.querySelectorAll("*")).filter(el => el.scrollWidth > document.body.clientWidth)
Open and close the mobile menu. Trigger every dropdown. Confirm nothing is clipped, overlapped, or inaccessible.
Scroll from top to bottom at each breakpoint. Fixed elements can overlap content at specific scroll positions that are invisible at page top.
Drag the window edge from 320px to 1920px. Watch for sudden layout jumps that indicate a missing breakpoint in your CSS.
On mobile viewports: does the page zoom when you tap an input? If yes, check font-size on that input.
For tap targets: are all buttons and links at least 44×44px? Use DevTools to inspect computed width and height.
Do all images have max-width: 100%? Are any images blurry because a fixed px width forces them larger than their natural size?
On desktop (1440px+): are paragraphs constrained to a readable line length (60–80 chars)? Full-width prose on a 1920px screen is hard to read.
screensize.io opens real browser windows at exact pixel dimensions — not DevTools simulations. Here is how to apply the strategy above with it:
Enter your URL and open 375px, 768px, 1280px, and 1920px at the same time. Arrange them side by side to compare layout transitions visually.
At each window: is there a horizontal scrollbar? If yes, open that window's DevTools to isolate the offending element before moving on.
Use the 8-step checklist above. The popup windows stay open while you work, so you can quickly switch between viewports to compare behaviour.
After fixing a bug, re-open the relevant popup windows with the updated URL (or a localhost build) to verify the fix does not introduce a regression at another breakpoint.
Prioritize 375px (standard phone), 768px (tablet portrait), 1280px (laptop), and 1920px (desktop). These four cover the overwhelming majority of real-world traffic. Then add 320px and 430px to cover the smallest and largest common phones.
The most common issues are horizontal overflow (elements wider than the viewport causing a scrollbar), text too small to read on mobile, tap targets smaller than 44×44px, images that overflow their containers, and navigation that breaks or collapses poorly on narrow screens.
Horizontal overflow is the single most common bug — caused by elements with fixed pixel widths, absolute-positioned elements that escape their container, or tables wider than the viewport. You can detect it with: document.querySelectorAll("*").forEach(el => { if (el.scrollWidth > document.body.clientWidth) console.log(el) })
No — test at your chosen breakpoints plus a few widths between them. The goal is to verify your layout transitions smoothly at every breakpoint and does not break at arbitrary widths in between. Checking 5–8 viewport widths per page is usually enough to catch all layout issues.
screensize.io opens real browser windows at the exact dimensions you choose, so scrollbars, browser chrome, and rendering are identical to what a real user sees. DevTools simulates a viewport inside an existing window, which can mask overflow issues, scrollbar width differences, and popup interactions.
Need the exact pixel dimensions for a specific device? Browse the Common Device Screen Sizes reference →
Want to understand why screen shapes affect layouts differently? Read the guide to understanding aspect ratios →
New to responsive testing concepts? Learn why testing different screen sizes matters →
Use screensize.io to preview your website at any of these resolutions instantly — no DevTools needed.
Open screensize.io →