You May Be Wrong About Breakpoints

Responsive breakpoints have been a cornerstone of web design for over a decade. Benchmarks like 768px and 1200px have become unofficial standards, inherited from an era when many web designers thought in terms of “what device are they using?”. But is that question still relevant in 2025?

My answer is yes, but with an asterisk. Device and viewport matter more than ever, but I think designers need to modernize their approach for building, testing, and prescribing responsive designs.

A Quick Primer

For those who are unfamiliar, I’ll get the technical out of the way.

Put simply, a breakpoint in web design usually refers to a CSS media query which allows conditional styles to take hold under set circumstances.

For example, screens narrower than 1200px:

/* My element is green */
.my-element {
   background-color: green;
}

/* But when the viewport is under 1200px it should be purple */
@media screen and (max-width: 1199px ) {
   .my-element {
      background-color: purple;
   }
}        

You can make a ton of super useful distinctions with media queries, not just browser size, but max-width and min-width are the most used by far. It is standard practice to establish several breakpoints that allow us to deliver optimized designs relative to the device or window size.

So What's The Problem?

I noticed a pattern. I various roles, I've seen Figma designs handed off at sizes matching established breakpoint values. This may be what engineers had requested, and it makes sense on its face: prescribe design changes in the context that triggers the change. Ironically, I think in doing so designers create larger blind spots and threaten the integrity of an otherwise elegant design.

I am a huge proponent of designers learning more about code and its implementation. But in many organizations, design artifacts still boil down to a static Figma asset. Yes, there are prototypes, but they a rarely exhaustive. This leaves a wide margin for interpretation and assumption.

Breakpoint values are crucial bits of technical information for a designer. However, for reasons I will get into below, I believe they are actually the worst viewport sizes for a designer to focus all of their energy on.

Breakpoints Are Thresholds, Not States

Colloquially, one could refer to widths ranging from a large phone to a small laptop as falling within a “medium breakpoint”, possibly targeting viewports between 768px and 1200px in width.

From a technical standpoint, this may be significant and true, assuming the query aligns with those values. However, from a design perspective this can be misleading and problematic.

By fixating on breakpoints, designers risk ignoring all of the other possible widths existing between those breakpoints. A more accurate and helpful terminology would be “breakpoint range” or “viewport range”. If only to acknowledge that each static artifact we propose suggests a myriad of other possible sizes.

So Many Screens

I would argue that directly targeting devices may have been wrong in the first place…

Old heads will remember a stretch of time when the number of smart mobile devices actually felt finite and manageable. For example, if you were an Apple user, we could confidently assume your mobile browser width would be one of three sizes…

• 320px: iPhone 3/4
• 768px: iPad in portrait mode
• 1024px: iPad in landscape mode

It isn’t like that anymore. While Apple is still the big dog, there are a lot of players on the field. If we only considered the smart phone options offered within the past three years, the number of unique sizes is likely in the dozens, if not hundreds. It simply isn’t feasible to prescribe a behavior to specific devices.

And Desktop?

Consider the windows on your desktop. While your monitor size is fixed, your browser window is completely fluid. Web analytics may inform me the most popular monitor sizes of my audience, but says nothing of how those users resize their browsers (thinking about this metric makes my head hurt).

Even if you are all about mobile, this wrinkle sticks. Variable window/app size is likely to continue further as smart devices add more multitasking functionality and foldable displays become more popular.

This is all to say, short of extensive and continuous user research, it might be time to stop assuming you know the specific size your users are consuming. Also, if defined breakpoints no longer accurately represent the exact viewport of our users, our range of accountability also shifts.

Breakpoints Are Opportunities

We’ve identified that pre-established breakpoints are points existing along a linear scale. They allow us to make designs better suited for the current viewport–a super helpful mechanism, but not a requirement!

Rather than thinking about responsive pages as having mobile, tablet, and desktop versions, we could approach each page as a single, flexible design. We could lean into the dynamism of fluid UI, choreographing components so their display needs align with these breakpoint opportunities.

A New Playbook

It may be appropriate to define a more fluid approach to designers' due diligence. I have some suggestions.

New Normal 1: Identify Sweet Spots

This is an easy one: bug an analyst for any data referring to users' devices and screen sizes. If there's a dashboard for it, bookmark it. Identify where most of your traffic is clustered, keeping in mind that larger desktop viewports should be taken with a slight grain of salt. That will tell you where your priorities are.

New Normal 2: Responsible Pressure Testing

Say we are designing a screen at 768px. Going up from our narrow range, we hit 768px, which is the cue for our design to snap into our medium range.

But what about the pixel RIGHT before we snap into medium? In this case, that would be 767px. If you're only designing for the breakpoint, there's a good chance it looks pretty jacked, or at least stretched a little thin.

This exposes another reason why I think breakpoints should not be a designer’s main focus: they often represent the most hostile extremes. Not an ideal canvas for our blue-sky design. However, since users could be viewing at these hostile size, we still have a responsibility to pressure tested those breakpoint-adjacent sizes.

New Normal 3: Flexible Design Artifacts

Now you may be saying "So you want me to double or triple the number of comps I make? Go kick rocks."

Not necessarily.

Using Figma auto layout, especially with the more recent addition of min/max widths, a designer can remarkably close to in-browser behavior. For example, you could easily bookend their viewport frame with a min/max that aligns with the breakpoint range being addressed.

Figma has a few gaps to fill before it reaches full responsive design parity, but it's getting close. Assuming the inner design is flexible and utilizes auto layout features, it's totally possible to hold your entire breakpoint range in a single frame.

A dynamic artifact like this will likely require more time at first, but the added design coverage pays off. Especially if your engineer still wants to see that screen at 768px.

Just Let Go, Maybe

My advice is to stop thinking about these things as problems to solve.

The beautiful and awkward truth of designing for web is that many crucial factors are out of our control. Along with viewport size, there is network performance and a rainbow of accessibility needs we must also consider. These are the natural forces of the web.

The best path forward may be to accept these gotchas not as problems but as responsibilities. With a more fluid approach to formal design, we can pursue their resolution with more single-minded intention.