Breakpoints are often chosen by copying a list of device widths, which produces a stylesheet full of rules that match nothing in particular. There is a better method, and it starts by not choosing breakpoints at all until the layout tells you where they are needed.
What does building fluid first mean?
It means writing the layout with flexible units so that it works across a range of widths without any queries at all. A grid with auto-fit and a minmax, flex items with flex: 1, and spacing in rem all adapt without help.
/* a card grid that works at every width, with no media query */
.cards {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(16rem, 100%), 1fr));
gap: 1.5rem;
}
A page built this way has far fewer breakpoints, because the components handle their own range and only the page-level layout needs help. That is the practical payoff of fluid-first: fewer queries, less code, and a stylesheet that behaves sensibly at widths you never tested.
How do I find the width where it breaks?
By narrowing the window slowly and watching. The steps are short.
1. open the page in a wide window
2. narrow the window in small steps
3. note the width where text starts wrapping badly
4. note the width where elements start overlapping
5. note the width where a component stops making sense
6. add a query just below each of those widths
Those three symptoms — bad wrapping, overlap, and a component that no longer makes sense — are the real breakpoints. They come from your content, not from a device list.
Why do content-driven breakpoints win?
Because content is what determines whether a layout works, and content changes over time. A sidebar that fits comfortably today may not fit when a heading is reworded, or when a translation makes the labels longer. A breakpoint derived from a device width says nothing about either case.
/* a breakpoint chosen by where the text stops fitting */
@media (min-width: 44rem) {
.article-layout { grid-template-columns: 14rem 1fr; }
}
Notice that the number is not a round device size. It is the width at which that particular layout starts working, and it will change as the content changes — which is the point. You will revisit it, and you will know why it was there.
What about the standard device widths?
They are useful as a testing checklist rather than as a source of breakpoints. If your layout has to work on a range of devices, check it at the narrow end of that range — around 320 pixels for the smallest phone still in use — and at a couple of common widths in between. If the layout holds at 320 and at the widest desktop, it will hold almost everywhere.
test widths
320px the narrowest case worth supporting
375-414px common phone widths
768px the classic tablet width
1024px a small laptop or a large tablet in landscape
1440px+ a desktop
The other argument against device breakpoints is that the device list is a moving target. Foldable phones, tablets in landscape and small laptops all blur the categories, and a layout designed around four named devices will look wrong on the fifth thing somebody buys.
What if I have too many breakpoints?
That is usually a sign that the components are not fluid. A stylesheet with a query for every 200 pixels is a symptom of hard-coded widths, not of a need for that many layouts. The fix is to go back to the components and make them flexible, and the queries will collapse into a couple.
a smell: 4 queries for a page that should have 1
a cause: a component with a fixed width
a fix: make the component fluid, then delete the queries
Another sign of too many breakpoints is that the values are scattered. If the queries are 30rem, 47rem, 63rem and 78rem, and nothing in the content corresponds to those numbers, they were probably chosen arbitrarily. A handful of breakpoints that each correspond to a visible change in the layout is a healthy number.
How do you check that a breakpoint works?
A breakpoint you guessed at is a breakpoint that will break later. The test is simple: narrow the window slowly and watch the layout, rather than resizing to a list of device sizes and hoping.
Turn on the device toolbar in your browser's devtools and set the width by dragging the handles rather than by picking a device. Then step down through the interesting widths in small increments - five or ten pixels at a time - and watch for the moment the layout stops working. That moment is your breakpoint, and it is a property of your content rather than of a phone that shipped last year.
Three signals tell you that a layout is breaking. Text that wraps into a very short last line, or a heading that spills onto three lines when it used to take two. A gap that was comfortable becoming a cramped squeeze. And an element that was meant to sit beside something now sitting under it, because the side-by-side arrangement no longer has room.
<!-- a row that breaks when the columns get too narrow -->
<div class="feature-row">
<div class="feature">
<h3>Fast</h3>
<p>Pages render in under a second on a normal connection.</p>
</div>
<div class="feature">
<h3>Simple</h3>
<p>Nothing to install, nothing to configure.</p>
</div>
</div>.feature-row {
display: flex;
gap: 1.5rem;
}
/* the row stacks before the columns get unreadably narrow */
@media (max-width: 32rem) {
.feature-row {
flex-direction: column;
}
}Record the width at which the layout breaks, then put the breakpoint just below it - not at the round number near it. 32rem is a real measurement; 30rem is a guess that happens to be a round number, and it is a few pixels too early for the layout you just tested.
The last check is the one people skip. After you have found the breakpoint, change the content - a longer title, a longer word in another language, a number that grows by a digit - and check again. A layout that only works with the sample text is a layout that will break the first time real content arrives.
Quick reference
- Build fluid first — flexible components need no queries.
- Find breakpoints by narrowing the window and noting where the layout breaks.
- Three symptoms: bad wrapping, overlapping elements, a component that stops making sense.
- Use device widths as a test checklist, not as the source of breakpoints.
- Test at 320 pixels and at a wide desktop; if both work, the middle works too.
- Too many queries usually means hard-coded component widths.
Try it yourself: build a page with no media queries at all, using a fluid grid and flexible components, then narrow the window until something breaks. Add exactly one query at that width. Repeat for the next problem. Count the queries — it is usually fewer than you expected.