Most designers pick breakpoints from a short list of common screen widths and call it responsive. The problem is that screens don’t break at the same point your content does. The right breakpoints come from your layout, not from a historical list of device dimensions.
The Device-Width Trap
The standard breakpoints (320, 768, 1024, 1440) are a historical artifact. They reflect dominant screen sizes from a particular era, not any principle of good layout. New devices arrive constantly with new dimensions, and designing to a fixed device list is always playing catch-up.
The underlying pattern is breakpoints added reactively. Something looks broken on a phone, so a breakpoint gets added. Something is off on a wide monitor, so another appears. After a year of this, a project typically has six or seven breakpoints, most of which don’t correspond to anything meaningful about the content. The same problem applies at the structural level: without a principled foundation, interfaces accumulate fixes rather than develop logic. The core UI design principles that govern hierarchy, alignment, and consistency apply equally to how a layout adapts across viewports.
Set breakpoints where your content breaks, not where your device list ends.
Breakpoints built around content produce fewer of them, each with a clear rationale that survives a redesign.
Start Without Breakpoints
The most practical exercise in responsive layout is to build with no breakpoints at all, then slowly widen the viewport until something breaks. Not “looks slightly different,” but actually breaks: text overflowing its container, a grid becoming unreadably wide, navigation that no longer fits, an image losing its focal point.
That width is where the breakpoint belongs.
This is the core of mobile-first design in practice. Start narrow, expand until the layout fails, then catch it just before that point. You’re letting the content tell you when it needs help, rather than imposing structure from a device-width assumption.
A common objection is that this takes longer than picking from a preset list. It takes about the same time, and it produces breakpoints you can actually justify.
How Many Breakpoints?
Most sites need three to five. The number follows the complexity of the layout, not the number of device categories in a slide deck. A simple editorial page may genuinely need two. A product page with a data table and a collapsing sidebar might need six just in those two components.
The mistake is applying the same breakpoints site-wide, uniformly. A global breakpoint at 768px makes sense for the navigation. It may have nothing to do with when a pricing table stops working.
Component scope vs. global scope
Global breakpoints handle layout-level decisions: the number of columns in the main grid, whether the sidebar is inline or collapsed, whether the navigation condenses into a toggle.
Component breakpoints handle the specifics. A card grid might reflow from three columns to two at 900px, and that decision belongs to the card, not the page. Container queries, well-supported in modern browsers, make this distinction much cleaner to express in CSS than adding another entry to a global list.
Reading the Content’s Signals
Several concrete signals indicate where a breakpoint belongs.
Line length. Body text reads best at 60–75 characters per line. Consistently shorter than 45 or longer than 90, and the layout needs adjustment. This is a content signal, not a device signal. Web typography systems go deeper on why line length matters as much as typeface choice.
Grid column collapse. Columns become too narrow to hold their content without awkward wrapping. That point depends on what’s in the column: a card with a thumbnail and two lines of text fails at a different width than a column of plain prose.
Image focal points. When a key subject (a face, a product detail) is consistently cut off at a particular viewport width, the layout needs art direction at that point, not just scaling. The breakpoint exists because of what’s in the image.
Navigation overflow. Navigation labels are a fixed set of text items. When the viewport is too narrow to hold them in a row without wrapping or truncating, that’s a content-driven breakpoint. The exact pixel value depends on label length and item count, which is why it varies between sites.
A Practical Method
Here is a repeatable process for finding breakpoints without guessing:
- Build the layout mobile-first with no breakpoints.
- Set the browser viewport to 320px wide.
- Drag the viewport wider, watching for the first moment something breaks in a meaningful way.
- Note the viewport width. Add a breakpoint just below that point.
- Continue widening and repeat until the layout holds at large widths.
Document the reason for each breakpoint in a comment in the CSS. If you cannot state the reason, the breakpoint probably shouldn’t be there.
This process works best when the underlying spacing system is already coherent. If the spacing scale is consistent (see spacing systems and the 8pt grid for how to establish one), the reflow at each breakpoint stays proportional rather than looking like two separate designs patched together at an arbitrary width.
Naming Breakpoints
Once you’ve found your breakpoints, name them by what they describe in the layout, not by the device you imagine is viewing it. nav-collapsed is more useful than mobile. grid-two-col is more useful than tablet. A name that describes the layout state makes it clear which component owns the breakpoint and why it exists.
In CSS, this maps naturally to custom properties or a Tailwind configuration object. A named breakpoint is also easier to audit when the design changes. If a layout is redesigned and a breakpoint is no longer needed, a descriptive name makes it obvious what to remove and confident that nothing else depends on it.
How Strynal approaches responsive breakpoints
Breakpoints are a structural decision, not a finishing step. At Strynal, they’re part of the layout system from the first wireframe, defined alongside the grid and the type scale, not added later to fix something that’s already broken.
Every breakpoint we add has a documented reason tied to the content it serves. The result is fewer breakpoints, each with clear intent, rather than a growing list of device-specific patches that need revisiting with every redesign.
Our UI/UX service covers the full design-to-build process: layouts that adapt because they’re built around real content, with breakpoints that survive the next screen size no one has thought of yet. If your current site reflows awkwardly or needs patches every time a new device arrives, get in touch and we’ll look at the structure beneath it.