The widths to test come from the points where the design breaks. A list of device models doesn't make that decision. The right method is to narrow the browser, mark the widths where the layout breaks, and put your breakpoints there.
Why a list of popular devices isn't enough
Working from a device list creates two problems. The list goes stale every year, and the widths in between stay untested. A design can look fine at 390 pixels and 768 pixels but break at 520.
Media queries don't look at device identity — they look at the viewport measurement. In MDN's media queries documentation, the conditions are defined in terms of width, height, and orientation.
How to find a breakpoint
The sequence goes like this.
- Start the browser at its narrowest and widen it slowly.
- Note the first width where a line of text runs too long, cards no longer fit side by side, or an image overflows.
- Make that width a breakpoint and rebuild the layout there.
- Repeat from tablet up to desktop.
For most interfaces, three to five breakpoints are enough.
Three checks beyond width you shouldn't skip
Touch targets. On a small screen, buttons have to stay big enough to press with a finger.
Text-to-background contrast. Even if color choices don't change on a small screen, readability has to be measured.
Horizontal scroll. The page body must not shift sideways at any width.
The content to test is a choice too. The longest product name, the longest client name, and the most crowded table should be tried on a narrow screen. A test done with short sample text doesn't show where a page running on real data will overflow.
Bringing the test onto one screen
Seeing the same page side by side at three different widths finishes these checks in one pass. Simulator Panel opens one address at several device sizes at once and takes screenshots, and the captured images drop into a Lodrive folder as a review package. The design-side modules are on the Designers page.
Here's the limit: Simulator Panel emulates the viewport — it doesn't run on a real device. To catch device-specific browser bugs and touch behavior, a final check on a real phone is still needed.
Pre-launch performance thresholds sit in the Web Analyzer breakdown.
FAQ
How many breakpoints should there be? For most interfaces three to five are enough. The number comes from the widths where the design breaks.
Should you design mobile-first? Starting from the narrow screen forces you to prioritize content, which simplifies the layout. Starting wide and narrowing usually produces more fixes.