Responsive design breakpoints: break where the content breaks
Good breakpoints come from the content, not from a list of phone and tablet widths. Start with the narrowest layout, widen the browser until something looks wrong (lines too long, cards too stretched, a nav that no longer fits) and add a breakpoint there. Most small sites need two or three. For components that sit in different-sized spaces, container queries do the job better than media queries.
Why device widths make poor breakpoints
Lists of common breakpoints, such as 375, 768, 1024 and 1440, describe screens that were popular at some point. Phones and tablets now come in dozens of widths, browser windows on laptops are resized freely, and a foldable can be two sizes in a minute. A layout tuned to exact device widths looks right on those devices and odd just either side of them. A layout whose breakpoints sit where its own content stops working looks right at every width in between.
That doesn't make the familiar numbers useless. They're good widths to test at, because many visitors arrive at roughly those sizes. They just shouldn't decide where the layout changes.
Finding breakpoints from content
- Build the single-column layout first. It's the simplest and it works at any width; see mobile-first web design.
- Widen the window slowly with developer tools open, watching the content rather than the ruler.
- Note the first width where something fails: body lines pass about 75 characters, a card becomes absurdly wide, an image is huge and blurry, or there's room for two columns that would read better.
- Add a breakpoint just before that width and change only what needs changing.
- Repeat until the layout is comfortable at the widest screen you care about. Then cap the content width rather than adding more breakpoints.
Each component can have its own breakpoints. The header may need to change at a different width from the pricing table, and that's fine. What you want to avoid is a pile of near-identical breakpoints at 767, 768 and 770 pixels that nobody can explain.
Writing media query breakpoints
MDN's guide to using media queries covers the modern range syntax, which reads more clearly than min-width and max-width: @media (width >= 48em) means 48em and wider. Using em for breakpoints ties them to the text size, so a visitor who sets a larger default font gets the narrower layout sooner, which is usually what they need.
- Use fluid values between breakpoints.
clamp()for type and spacing,minmax()andauto-fillfor grids, so the layout adjusts continuously and breakpoints only handle real changes of structure. - Never let a breakpoint be the only thing preventing overflow. Use
minmax(0, 1fr)columns andmax-width: 100%on media so nothing escapes the screen at an untested width. - Test at 320px. WCAG's Reflow criterion asks that content works at 320 CSS pixels wide without scrolling in two directions, which is also what a 1280px window looks like at 400% zoom.
Container queries: breakpoints for components
A media query asks how wide the screen is. A card doesn't care about the screen; it cares about the space it's been given, which might be a full-width row on the home page and a narrow sidebar elsewhere. Container queries let it ask that instead. Mark the wrapper with container-type: inline-size, then write @container (width >= 30em) { ... } rules for the card. The same component then lays itself out correctly wherever it's placed.
| Media queries | Container queries | |
|---|---|---|
| Asks about | The viewport | The nearest container you've marked |
| Best for | Page-level structure: header, page columns, overall spacing | Reusable components: cards, media objects, forms |
| Needs | Nothing extra | container-type on an ancestor |
| Typical mistake | Breakpoints copied from device lists | Querying an element that isn't a container |
Breakpoints in Anticode
Anticode's design systems are responsive by default. In design-engine pages, grids are built from minmax(0, 1fr) columns, type and section spacing scale with clamp(), and the stylesheet has a few structural breakpoints: below 860px, two-column hero and split layouts stack and three-card grids drop to two, and below 600px most grids drop to one column. Layouts you change in the layout editor compile to fluid CSS in which a frame only splits into columns inside a container query, once each child has room for its minimum width.
App builds, which the model writes as a whole program, are opened at phone and laptop widths in a headless browser during self-review when that service is available, and problems the Critic sees in the screenshots are fixed before you see the build. For a broader check, see testing a website on mobile.
Questions people ask
What breakpoints should I use?
The ones your content needs. Start narrow, widen until the layout fails, and add a breakpoint there. Test at familiar device widths, but don't design to them.
Should breakpoints be in px or em?
Em is generally better, because the layout then responds to the visitor's text size as well as the screen.
How many breakpoints does a site need?
Usually two or three for page structure, plus fluid sizing in between. Components can add their own with container queries.
Sources
- Using media queries, MDN Web Docs, checked
- Container size and style queries, MDN Web Docs, checked
- Understanding SC 1.4.10: Reflow, W3C, checked