Choosing CSS breakpoints for responsive design

Why the device list is a lie

A "480px, 768px, 1024px" breakpoint list looks complete and is mostly nostalgia. A phone can be 360, 393, or 430 CSS pixels; a tablet folds; a desktop screen spans 1280 to 2560; and the same page sits in a 900-pixel sidebar and a 1080-pixel browser window. Breakpoints belong to the layout, not to marketing screenshots.

The correct rule: a breakpoint is wherever the layout stops working. Pick it when the content begins to cramp, the text gets hard to read, or columns strain.

Mobile-first ordering

Write the base (mobile) styles with no media query, then use min-width media queries to add layout as the viewport grows:

/* base: the single column */
.card { padding: 1rem; }

@media (min-width: 640px) {
  .card { padding: 1.25rem; }
}

@media (min-width: 960px) {
  .grid { grid-template-columns: repeat(3, 1fr); }
}

The ordering is important: min-width queries apply upward, so the mobile-first pattern means the smaller CSS is the default and each query overrides only the parts that change. max-width queries for desktop build the opposite way and are easier to get tangled in when a new layer appears.

CSS also gives a cleaner team default:

• Use min-width, write mobile first, and keep the queries you need.
• clamp() replaces most font and spacing queries (font-size: clamp(1rem, 2vw + 0.5rem, 1.25rem)).
• Reduce the query count, and test the actual DOM at each breakpoint with real content.

Choosing breakpoints from the layout

The honest method:

1. Start at the mobile width and test with the content. Write the base.
2. Widen the viewport in the browser until a component breaks (a card keeps two columns squeezed, a form-label wraps ugly).
3. Note that width, and put a min-width: <that> query just below it.
4. Repeat, and you end up with a few breakpoints per component.

In practice, most sites end up around four usable breakpoints even when they set six, because the CSS does not need a new breakpoint for every device, it needs one for every layout change. The responsive basics article covers the viewport meta and overflow checks that sit alongside breakpoints.

Container queries when components are the unit

Viewport breakpoints assume the whole page is the layout. The moment a component (a card, a nav, a message box) is dropped into a sidebar, in a narrow grid cell, or inside a dialog, the viewport does not tell the truth. Container queries fix that:

.card-list {
  container-type: inline-size;
}

@container (min-width: 380px) {
  .card { display: flex; }
}

Now the component responds to the size of its own container, not the viewport. Use container queries for genuinely reusable components and CSS Grid for the page level, and keep the viewport media queries for the page chrome.

The pitfall that matters

The failure mode of fixed breakpoint lists is not the specific number; it is the claim that a number list is the answer. The answer is: build base-first, add min-width rules where the layout changes, verify at real widths with the audit and DevTools device mode, and only then translate to "the site supports mobile at ~320px and desktop at 1280px".

The layout techniques guide gives the Flexbox/Grid choices inside a breakpoint, and the semantic HTML article keeps the content readable while widths change.