Should Your CSS Breakpoints Match Devices? Stop It.

Imagine you’re knee-deep in a responsive redesign. The client hands you a list of the latest phones and tablets—375px, 768px, 1024px—and asks, “Will our site look perfect on all of these?” You nod, add a few media queries, and ship it. But a week later, you’re debugging why a card component looks cramped inside a sidebar on a 1440px desktop. The device-based breakpoints you chose have nothing to do with the actual content. This is the trap we keep falling into.

The core question: should we set breakpoints based on specific devices or viewport widths, or should we let our content and components decide when to reflow? The answer, as we’ll argue, is to stop chasing device sizes and instead build with container queries and content-first breakpoints. It’s a shift that saves us from endless tweaking and makes our layouts genuinely responsive.

The Illusion of Device Breakpoints

For years, the standard practice was to define breakpoints at common viewport widths like 375px, 768px, 1024px, and 1440px—numbers that seem to correspond to popular devices (MDN Web Docs). But here’s the problem: those numbers are moving targets. New phones appear constantly, and the viewport is not the same as the device screen. A breakpoint at 768px might work for an iPad in portrait, but what about a foldable phone that’s 700px wide? Or a browser window resized to 800px on a desktop? The viewport is the only thing CSS can sense, and it doesn’t care about pixels on a spec sheet.

More importantly, content doesn’t live at the viewport level. A card in a sidebar might need to stack at 500px container width, while the same card in a full-width hero can stay side-by-side until 900px. Device-based breakpoints force the entire page to respond to the viewport, ignoring the context of individual components. That’s why we end up with media queries that feel like a patchwork of magic numbers.

Container Queries: A Better Way to Think

Enter container queries. With @container, you can style a component based on the size of its parent container, not the viewport (MDN Web Docs). This is a fundamental shift: instead of designing for the whole page, you design for the container. Container queries are Baseline Widely available, in browsers since February 2023 (MDN Web Docs), so there’s no excuse to keep avoiding them.

The benefits are immediate. You can create a card component that adapts whether it’s placed in a narrow sidebar or a wide main column, without writing a single viewport media query. And container query length units—like cqw (1% of container width) or cqi (1% of container inline size)—let you size typography and spacing relative to the container, not the viewport (MDN Web Docs). This granularity is what we’ve been missing.

But container queries aren’t a silver bullet. They require a bit of planning: you need to designate which elements are containers and ensure they have a containment property. And for truly page-level layouts (like a global nav collapsing), viewport media queries are still necessary. So the real answer is a hybrid approach: use container queries for components, and use viewport breakpoints only for broad layout shifts—but choose those breakpoints based on your content, not on a list of devices.

Content-First Breakpoints: The Only Numbers That Matter

When you do need a viewport breakpoint, forget the device list. The only rule is: add a breakpoint when the content demands it (MDN Web Docs). That might be at 640px because your navigation can’t fit on one line, or at 900px because your grid of cards starts looking too cramped. The exact number depends on your layout, your typography, and your content. A common approach is to start with a mobile-first design—build for the smallest screen, then add breakpoints as you expand. This is what MDN recommends as part of responsive design (MDN Web Docs).

To find the right breakpoints, resize your browser slowly and watch for the moment when the layout starts to break. That’s your cue. It’s a judgment call, but it’s grounded in your content, not a spec sheet. As a rule of thumb, you might find that 375px, 768px, and 1024px are useful reference points—they are common in the wild (MDN Web Docs)—but they are starting points, not targets to hit.

This approach also aligns with accessibility. WCAG 2.1 Reflow (Level AA) requires that content can be presented without two-dimensional scrolling at a width equivalent to 320 CSS pixels (W3C WCAG 2.1 Understanding Reflow). That’s a content-driven constraint: your layout must work down to that narrow width, which means your breakpoints need to kick in before things get unusable. If you design for content, you’ll naturally meet that requirement; if you design for devices, you might miss it.

Choosing Between the Two: A Practical Comparison

To see the difference, let’s compare two approaches for a typical product card that appears in a sidebar (300px wide) and a main content area (800px wide).

As the table shows, neither is inherently better—they solve different problems. The mistake is using only one. A modern responsive design uses both: container queries for components, viewport breakpoints for the overall page skeleton, and content-first breakpoints chosen when the layout starts to complain.

Putting It Into Practice

Let’s apply this to a real scenario. Say you’re building an e-commerce product card. Instead of writing a media query at 768px to make the card stack its image and text, you’d set the card’s parent as a container and use @container (min-width: 400px) to switch from a stacked to a side-by-side layout. That way, the card looks great in a 300px sidebar (stacked) and in a 800px main column (side-by-side), with no extra viewport queries. You’d still use a viewport breakpoint to decide whether the sidebar appears at all—say, when the viewport is below 900px, you might hide the sidebar and move the card into a single column. That breakpoint is chosen because your content (the sidebar) can’t fit otherwise.

Quick tip: When you set up container queries, remember to define a containment context on the parent with container-type: inline-size—otherwise, the queries won’t fire.

This approach also plays nicely with modern CSS features like :has() and subgrid, which let you align nested items with the parent grid (MDN Web Docs). But the key is to stop thinking in terms of “mobile” and “desktop” and start thinking in terms of “narrow container” and “wide container.” Your CSS will be more maintainable, your components more reusable, and your users won’t care about device names—they’ll just enjoy a site that works.

Bottom Line

Stop setting breakpoints based on device widths. Instead, adopt container queries for components and choose viewport breakpoints based on your content’s needs. This is the only way to build layouts that truly respond to context, not just screen size.

Sources

• MDN Web Docs - https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
• MDN Web Docs (@container) - https://developer.mozilla.org/en-US/docs/Web/CSS/@container
• MDN Web Docs (container queries guide) - https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
• W3C WCAG 2.1 Understanding Reflow - https://www.w3.org/WAI/WCAG21/Understanding/reflow.html