Breakpoints in responsive design can be determined either by the dimensions of common devices (device-based) or by the layout’s natural breaking points (content-based). The key difference lies in what triggers the breakpoint — fixed device sizes versus flexible content needs.

Key Differences Between Device-Based and Content-Based Breakpoints

1
Device-based breakpoints are chosen based on specific screen sizes of popular devices (e.g., 320px for phones, 768px for tablets, 1024px for desktops).
2
Content-based breakpoints are chosen where the design or layout starts to break or look cramped, regardless of the device size.
3
Device-based breakpoints can become outdated as new devices emerge with varying screen sizes.
4
Content-based breakpoints provide greater flexibility and maintainability by responding to the actual needs of the design rather than fixed device dimensions.

Example: Content-Based Breakpoints in CSS

In this example, the breakpoints are not tied to specific device widths but are defined at points where the layout benefits from additional columns. This ensures the design adapts fluidly across any screen size.

Difficulty: 6/10

Topics: responsive design, media queries, device vs content adaptation

Scenario Questions

0-2 years experience

1
You're building a mobile-first card layout and notice it looks broken on an iPad — you’ve set breakpoints at 320px, 768px, and 1024px. What’s the most likely reason it’s not working as expected, and how would you fix it?
2
If you set a breakpoint at 768px to change the grid from 1-column to 2-column, but the content still wraps awkwardly on a 750px wide browser, what should you check first?
3
A teammate says 'just use max-width: 480px for mobile' — why is that not the same as using a device-based breakpoint like @media (max-width: 480px)?

2-5 years experience

1
Our product page layout looks fine on phones and desktops, but breaks on foldable devices and tablets in landscape — the breakpoints are based on common device widths. How would you debug and fix this without adding more device-specific rules?
2
We’re seeing inconsistent behavior across browsers on the same screen size — some render the mobile layout, others the desktop one. The breakpoints are device-based. What might be going wrong, and how would you approach this?
3
A designer insists we use breakpoints at 375px, 768px, and 1440px to match iPhone, iPad, and MacBook sizes. Why is this a problem long-term, and what’s a better alternative?

5-8 years experience

1
We’re redesigning our component library to support dynamic content resizing — like embedded widgets that change width based on parent containers. How would you architect the CSS breakpoints to avoid brittle device assumptions and ensure scalability across unknown contexts?
2
Our responsive grid breaks when users zoom in or use accessibility font scaling — current breakpoints are device-based. How would you refactor to make it content-driven, and what performance or maintenance tradeoffs would you consider?
3
A legacy system uses 12 fixed device breakpoints for every component. We’re migrating to a design system. How would you convince the team to shift to content-based breakpoints, and what metrics would you track to prove it’s working?

8+ years experience

1
We’re building a global platform that must support everything from low-end tablets in emerging markets to 8K monitors in enterprise setups. How would you design a responsive CSS architecture that avoids device-based breakpoints entirely, and how do you handle cross-team alignment on this decision?
2
Our design system has 50+ components, each with its own device-based breakpoints. We’re seeing inconsistent behavior across products and high maintenance cost. How would you lead a migration to content-based breakpoints across engineering and design teams, and what long-term governance would you put in place?
3
A major partner’s app embeds our UI components in a custom iframe with unpredictable widths. Our breakpoints are device-based and now break constantly. How would you architect a solution that’s resilient to this kind of third-party embedding, and how do you communicate this as a systemic design principle?

Follow-up Questions

❓How do you decide when to use one over the other in a real project?
❓What happens if you rely only on device-based breakpoints for a tablet with a split-screen mode?
❓Have you ever seen a layout break because someone used device-based breakpoints incorrectly?