At what width should a navigation switch from a collapsed menu to a horizontal bar? The answer to that question has a name: the breakpoint, the threshold where a Media query flips the layout into a different behavior.
The word itself points to the right way to choose it: it names the place where something breaks, not a device width copied from a list found online.
Definition
A breakpoint is the width value used inside a media query to trigger a layout change. Below that threshold one behavior applies; above it, another takes over. A project can have a single breakpoint or several, depending on how complex its layouts are.
The trap of device-shaped breakpoints
A common habit is to choose breakpoints matching whichever popular device widths exist at the time a site is built: 375 pixels for one phone, 768 for one tablet. The problem is that those widths go stale the moment a new model ships, while the CSS stays locked onto the old one.
Setting the breakpoint from the content
The right method is to widen the browser window gradually and spot the exact moment the layout becomes uncomfortable: text stretched too long on one line, buttons overlapping, empty space growing excessive. That width, not a device width, becomes the breakpoint.
.nav {
display: flex;
flex-direction: column;
}
/* The threshold here is where the links start overlapping
on one line, found by widening the window, not a phone
screen width. */
@media (min-width: 640px) {
.nav {
flex-direction: row;
justify-content: space-between;
}
}How many breakpoints to plan for
A project that piles up breakpoints ends up maintaining as many versions of the same component as it has thresholds, which quickly becomes unmanageable. Most interfaces get by with two or three well-chosen breakpoints, each matching a genuine visual breaking point rather than one more device category.
The device emulation mode in developer tools helps spot these thresholds quickly, by resizing the window continuously instead of switching physical devices for every attempt. It still remains worth checking the result on a real device before treating a breakpoint as final, since some touch behaviors never simulate perfectly inside a desktop browser.
An alternative: not depending on a single global breakpoint
The same component, a card for instance, can be too narrow inside a sidebar and perfectly comfortable at full width, independently of the size of the screen displaying it. In that case, a Container query usefully replaces a global breakpoint, since it reacts to the space actually available to the component rather than the width of the whole window, which echoes the Mobile first philosophy: start from the bare essentials, then only add complexity where it is justified.
Frequently asked questions
Common habits exist, around 600, 768, 1024 and 1280 pixels, but none of them is a technical standard. They serve as a reasonable starting point, to be adjusted afterward by watching where the project's actual content really starts to deform.
Not necessarily. A small shared set of breakpoints used across the whole interface makes maintenance easier, but one isolated component whose behavior breaks at a very different threshold from the others deserves its own breakpoint rather than a compromise that suits nobody.
The media query is the CSS instruction itself, written with @media. The breakpoint is the width value written inside it. So a media query uses a breakpoint, but not the other way around: the breakpoint does not exist without the media query that puts it to work.