Responsive breakpoint guide
Responsive Breakpoint Checklist for Viewport Testing
Breakpoint testing works best when every width has a reason: the content changes, the layout changes, or the user could lose an important action.
Viewport coverage
Test the responsive ranges that users actually see, then add exact breakpoints from your CSS.
State coverage
Include open menus, sticky UI, forms, modals, loading states, and long content where breakpoints drift.
Release coverage
Keep screenshots and notes for the widths that block releases so the next pass starts faster.
The responsive breakpoint checklist
Use this checklist when adding media queries, reviewing a redesign, or preparing a release that changes layout CSS.
1. Start with content, not devices
- Open the page at 320px, 360px, 390px, 430px, 768px, 1024px, 1280px, 1440px, and 1920px.
- Mark the exact widths where navigation wraps, cards become cramped, tables overflow, or CTAs disappear.
- Create breakpoints only where the content needs a new layout rule.
2. Test around every breakpoint
- Check at least 1px below, exactly at, and 1px above each CSS breakpoint.
- Include framework defaults from Tailwind, Bootstrap, custom media queries, and component-level container queries.
- Repeat the pass for nav-open, modal-open, form-error, empty, loading, and long-content states.
3. Cover real viewport ranges
- Use small phone, large phone, tablet, laptop, and wide desktop ranges as the minimum responsive QA set.
- Add current iPhone and Android CSS pixel widths when mobile changes affect conversion or signup flows.
- Run one landscape pass for headers, sticky bars, drawers, and checkout forms.
4. Ship with regression evidence
- Capture screenshots before and after the change across the chosen viewport set.
- Block the release when content clips, controls overlap, horizontal scroll appears, or key actions move offscreen.
- Keep accepted breakpoint changes in the QA checklist so the next release starts from a known baseline.
Viewport ranges to include
These ranges keep breakpoint QA practical without pretending every device needs its own media query.
Tiny mobile
320px to 359px
Catches old phones, embedded webviews, narrow checkout forms, and fixed-width UI.
Mobile
360px to 430px
Covers common iPhone and Android widths where most responsive bugs are found.
Tablet
768px to 1024px
Shows whether a page should still be mobile, become two columns, or use tablet-specific spacing.
Laptop
1280px to 1440px
The everyday desktop range for dashboards, docs, pricing, and product pages.
Wide desktop
1536px to 1920px
Finds stretched heroes, long line lengths, weak grids, and content that stops scaling gracefully.
How to test a breakpoint
For every breakpoint, inspect the layout before the rule applies, at the exact threshold, and after the next layout takes over. That tiny three-width pass catches off-by-one CSS bugs, wrapped controls, and hidden overflow.
- Open the page at the breakpoint minus 1px.
- Check the exact breakpoint width.
- Open the page at the breakpoint plus 1px.
- Repeat with navigation, forms, modals, and sticky UI active.
CSS example
The checklist applies to framework screens, custom media queries, and container queries. The important part is testing the edges.
/* Test below, at, and above every breakpoint */
@media (min-width: 768px) {
/* tablet layout */
}
@media (min-width: 1024px) {
/* laptop layout */
}
@media (min-width: 1536px) {
/* wide desktop layout */
}Turn breakpoint notes into a QA pass
Use the free breakpoint finder to identify risky widths, then open the same page in Sizzy for synchronized responsive review and screenshots.
Related Sizzy responsive tools
Website Breakpoint Finder
Find the viewport widths where a page needs layout attention.
CSS Breakpoint Checker
Turn CSS media queries and framework screens into a QA matrix.
Viewport Checker
Check a viewport size, breakpoint category, aspect ratio, and CSS helper.
Responsive QA Checklist
Build a release checklist for layout, forms, media, and accessibility.
Responsive Screenshot Generator
Plan screenshot captures across phone, tablet, laptop, and desktop.
Browser Size Cheat Sheet
Choose practical browser and viewport sizes for repeatable QA.
FAQ
What is a responsive breakpoint checklist?
A responsive breakpoint checklist is a repeatable QA plan for testing widths below, at, and above the CSS breakpoints where a layout changes.
Which responsive breakpoints should I test first?
Start with small mobile, large mobile, tablet, laptop, and wide desktop widths. Then add the exact CSS breakpoints used by your site and test just below and above each one.
Should breakpoints be based on devices or content?
Use real viewport sizes for coverage, but create CSS breakpoints where the content breaks. Device lists are useful for QA, while content problems should drive the layout rules.
How does Sizzy help with breakpoint testing?
Sizzy lets teams inspect synchronized responsive viewports, compare page states, capture screenshots, and move from breakpoint checks into a broader responsive QA workflow.