Breakpoints

The most common breakpoint mistake is device targeting. A designer checks what the most popular phone screen widths are and sets breakpoints at 375px, 768px, and 1024px because those are the “mobile,” “tablet,” and “desktop” widths. Then a 430px phone launches, or a 1180px iPad, and the layout breaks at widths that the breakpoints did not anticipate.

The correct approach is content-driven breakpoints: resize the browser, watch the content, and set a breakpoint when the content starts to look wrong. No device list required.

What triggers a breakpoint

A breakpoint should be triggered by one of these conditions:

Line length becomes uncomfortable — body text should sit between 45 and 75 characters per line. When a narrow viewport compresses lines too short, the layout needs to change (larger type, different column structure) — or when a wide viewport stretches them too long, a max-width container kicks in.

The column count becomes impractical — a three-column card grid at 380px gives each card roughly 100px of width. Cards cannot render usefully at that width. The breakpoint adds a column count change: three columns becomes one column.

A navigation pattern stops working — horizontal navigation with six items works at 900px and fails at 480px. The breakpoint triggers a hamburger menu or a simplified nav structure.

A two-column layout runs out of room — a 300px main column plus a 200px sidebar plus gutters and margins requires at least 600px. Below that, the sidebar must drop below the main content or collapse into a menu.

How many breakpoints

Three to four breakpoints cover most layouts. The Tailwind CSS default scale — sm (640px), md (768px), lg (1024px), xl (1280px), 2xl (1536px) — gives five, but most designs use two or three of them meaningfully and leave the rest unused.

More breakpoints mean more maintenance. Each breakpoint doubles the number of layout states to design and test. Four breakpoints with three screen sizes between each means twelve possible states. Only add a breakpoint when the layout genuinely breaks without one.

The container max-width breakpoint

The most commonly overlooked breakpoint is the max-width container on wide screens. Without a maximum content width, text lines grow to seventy, ninety, a hundred characters on wide monitors — far beyond comfortable reading length.

Setting max-width: 1280px (or similar) on the page container and centring it with auto margins is not a breakpoint in the CSS sense, but it functions as one: at widths above 1280px, the layout stops widening and the surrounding space grows instead. This is the invisible breakpoint that prevents wide-screen layouts from becoming unusable.

Breakpoints and the grid

Breakpoints do not change content — they change the grid the content sits in. Tailwind’s responsive prefixes make this explicit: grid-cols-1 md:grid-cols-2 lg:grid-cols-3 means “one column by default, two at 768px, three at 1024px.” The content (the cards) is the same at all sizes. The grid structure adapts around it.

This is the clearest expression of the responsive principle: layout changes, content does not. The breakpoints mark where the layout changes, and each change is a deliberate design decision tied to a specific content-layout failure at a specific width.

Container queries

Viewport-based breakpoints have a structural limitation: a component doesn’t know how wide it is — only how wide the viewport is. A card component in a two-column layout has less space than the same card in a one-column layout, but a media query cannot detect this difference.

CSS container queries solve this by allowing a component to respond to the size of its containing element rather than the viewport:

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

@container (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 180px 1fr;
    gap: 1rem;
  }
}

The card switches from a stacked layout to a side-by-side layout when its container is 400px wide — regardless of whether the viewport is 800px or 1600px. The same card component works correctly whether it appears in a full-width section, a sidebar, or a modal.

Container queries are now supported in all major browsers and are the correct tool for component-level layout adaptation. Viewport breakpoints remain appropriate for page-level layout changes. The distinction: page structure responds to the viewport; components respond to their container.

The final section covers application: common layout patterns that reuse these principles to solve recurring problems.