Because they were built for a handful of imagined devices instead of for a range of widths. The design looks perfect at three sizes the designer checked and falls apart at every size in between. Real visitors do not arrive at your three sizes. They arrive at hundreds.
We see the same failures over and over. A heading that fits on one line at 1440 pixels and wraps into four at 1100. A three column grid that squeezes into unreadable slivers before it finally stacks. A navigation bar that collides with a logo somewhere around tablet width and stays broken.
None of this is a hard problem. It is a process problem. Teams pick breakpoints first and check the gaps last, when the right order is the other way around.
A breakpoint is a screen width where your layout changes. Below it, one arrangement applies. Above it, another does. Under the hood it is a media query, which asks the browser how wide the viewport is and applies different styles depending on the answer.
The word breakpoint carries a bad assumption though. It suggests the layout only needs to work at those specific widths, when in reality the layout has to work at every width. A breakpoint is where you intervene, not where the design lives.
The healthier way to think about it is that your layout should be fluid by default and your breakpoints should handle the moments where fluid stops being enough. Modern CSS makes that far easier than it used to be, which is why the number of breakpoints most sites need has actually gone down.
Design to your content. Choosing breakpoints because a popular phone is a certain width means chasing a target that changes every year. Choosing them because your layout visibly breaks at a certain width means solving the actual problem, and that decision keeps working when new devices ship.
The method is simple and takes ten minutes. Open your page in a browser and drag the window slowly from very wide to very narrow. Watch for the moments something looks wrong: text lines get too long, a card gets too cramped, an image gets too small to read. Those moments are your breakpoints.
This approach produces odd numbers, and that is fine. There is nothing special about 768 pixels. If your layout breaks at 840 because that is where your three column grid stops working, then 840 is a better breakpoint than a round number you inherited from a framework.
It also produces fewer breakpoints, because you only add one where something genuinely fails. Every breakpoint you add is another state to design, build, and test forever.
The market is far more fragmented than most design files assume. Statcounter Global Stats for July 2026 puts 1920x1080 at the top worldwide with 10.13% of screens, followed by 414x896 at 7.09%, 360x800 at 5.86%, 384x832 at 4.18%, 390x844 at 3.56%, and 1536x864 at 3.29%.
Read that list carefully, because it makes the argument for you. The single most common resolution on the planet accounts for roughly a tenth of screens. There is no dominant size to design for, and the long tail below those six is where most of your visitors actually are.
The mobile widths cluster in an interesting way too. The common phone widths sit in a fairly tight band, which means a layout that works well across roughly 360 to 430 pixels covers a large share of phone traffic without needing separate treatment for each one.
The desktop side is where teams overfit. Designing only at 1440 pixels because that is the designer's laptop produces sites that feel empty on a 1920 screen and cramped on a 1280 one. That is the gap our piece on designing mobile-first is really about closing.
Webflow ships with four: a desktop base plus tablet, mobile landscape, and mobile portrait. Webflow's documentation sets the tablet breakpoint at 991 pixels and below, and mobile landscape at 767 pixels and below, with mobile portrait covering the smallest screens beneath that.
The important part is how they cascade. The desktop base applies everywhere unless a smaller breakpoint overrides it, so styles flow downward. Change something at the base and it changes everywhere you have not specifically overridden, which is a feature once you understand it and a source of confusion until you do.
Webflow also lets you turn on three larger breakpoints at 1280, 1440, and 1920 pixels. These are worth enabling on content-heavy sites, because without them your layout simply stretches on large monitors and your line lengths get uncomfortable.
Our habit is to enable the large breakpoints and use them sparingly, usually only to cap a maximum content width and adjust type. Adding rules at every available breakpoint is how a Webflow project becomes unmaintainable.
Container queries let an element respond to the size of its container rather than the size of the browser window. MDN describes them as an alternative to media queries, where a media query asks about the viewport and a container query asks about a specific container element.
This solves a real problem. A card in a narrow sidebar and the same card in a wide main column are the same width of viewport but very different widths of space. With media queries alone you have to write rules that know where the component sits. With container queries the component figures it out itself.
The setup is straightforward. MDN documents that you declare a containment context with the container-type property, using inline-size when you only care about width, and then write rules inside an @container block that respond to that container's size.
They do not replace breakpoints, and we would not treat them as a full replacement yet. Page-level layout decisions are still genuinely about the viewport. Container queries are the right tool for components, and media queries remain the right tool for the page shell.
On support, the useful reference is Baseline, which web.dev defines in two stages: newly available means all four core browsers support it, and widely available means 30 months have passed since that point. Those four browsers are Chrome, Edge, Firefox, and Safari, and checking a feature's Baseline status is a faster answer than arguing about support from memory.
Most marketing sites need three, and some need two. One arrangement for phones, one for tablets and small laptops, one for large screens. If you find yourself adding a fifth and sixth, the layout is usually fighting you rather than the devices.
The reason fewer works now is that CSS got better at fluid layout. Grid and flexbox can reflow content without being told to at specific widths, and type can scale smoothly between a minimum and a maximum instead of jumping at each breakpoint. A lot of what used to require a breakpoint no longer does.
Every extra breakpoint has a real cost. It is another state for the designer to specify, another for the developer to build, another for someone to check on every future change, and another place for the site to be subtly wrong for months without anyone noticing.
The discipline that keeps this under control is a design system with defined spacing and type steps, so components behave predictably instead of each one being tuned by hand. We wrote about setting that up in our guide to building a design system for a website.
Let type scale smoothly rather than jumping. Modern CSS can set a minimum size, a maximum size, and let the browser scale between them based on the viewport, which removes most of the reason to restyle headings at every breakpoint.
The measurement that actually matters is line length, not font size. Text is comfortable to read at roughly 50 to 75 characters per line, and that number stays constant while your screen sizes do not. Setting a maximum width on text blocks does more for readability than any font size rule.
Headings need the most attention because they break worst. A heading sized for a wide screen becomes a wall of text on a phone, and one sized for a phone looks lost on a monitor. Checking your longest real heading at your narrowest width catches most problems in one look.
Do not forget that font choice interacts with all of this, since some typefaces hold up much better at small sizes than others. We covered how to make that choice in our piece on choosing the right fonts for a website.
Drag the window, do not just click device presets. Device presets check a handful of widths and miss everything between them, and between them is where layouts break. Slowly resizing from wide to narrow finds problems that preset buttons never will.
Then test on at least one real phone. Emulators get dimensions right and get everything else slightly wrong, including tap target size, scroll feel, how the on-screen keyboard covers a form, and how heavy the page really feels on a slower connection.
Check the awkward middle sizes deliberately. The range around 800 to 1100 pixels is where the most bugs live, because it covers small laptops and large tablets and gets the least attention. Landscape orientation on a phone belongs in the same category.
Finally, test with real content rather than the tidy placeholder text from the design. Real headings are longer, real names break differently, and real images have awkward proportions. Most responsive bugs are content bugs wearing a layout costume.
Open your own site and drag the window slowly from wide to narrow, and write down every width where something looks wrong. That list, which usually takes ten minutes to produce, is a better breakpoint plan than any set of standard device sizes.
Then fix the worst one rather than all of them. Responsive problems compound, and correcting the layout at the width where things first break often resolves several smaller issues further down.
After that, cap your maximum content width if you have not, and set your text blocks to a comfortable line length. Those two changes improve almost every site and require no new breakpoints at all.
If your site looks right in the design file and wrong on real devices, we are happy to take a look and tell you where it is actually breaking. Send us the URL at phoenix.studio and we will walk you through what we would change.
Tell us where you want to go. We'll tell you how we'd get you there.