Drag the edge of a browser window slowly inward on a well-built site and, at some point, the page changes its mind. Three columns become two, the menu folds behind an icon, or a sidebar drops below the article. The width where that switch happens is a breakpoint.
You don’t need to write code to judge whether a breakpoint is in the right place. You need to know what it is, what should decide where it goes, and how to describe a transition that isn’t working. That is what this guide covers.
Review Each Layout Change With Four Questions
When you notice the layout switching, run through this card. It works whether you are looking at a live page or at paired views from the team.
- Before the change: Is the current arrangement getting hard to read or use? Look for cramped columns, squeezed text, or controls that no longer fit.
- After the change: Does the new arrangement fix that problem?
- Across the change: Does any important content or the main action disappear, get hidden, or move somewhere unexpected?
- Have you seen both sides of the switch? If not, ask the team to show the layout just before and just after it changes.
The rest of this guide explains why those questions matter more than the exact pixel number.
What a Breakpoint Is
A breakpoint is a screen width where the design adjusts to a different layout. Nielsen Norman Group defines it that way and notes that, in practice, designers usually think of each layout as covering a range of widths, from one breakpoint to the next. MDN describes breakpoints as the points where the layout changes.
Not every change in size is a breakpoint. Within one layout, images can grow and text can wrap differently as the window widens. A breakpoint is where the arrangement itself changes, such as columns stacking.
A Review Size Is Not a Breakpoint
A review size is somewhere you choose to inspect the page. A breakpoint is a threshold where the layout’s rules change. The two get confused because both are written as pixel widths.
If you open a page at a common phone, tablet, and desktop size, you see the page at three sizes, which may or may not be three different layouts. You don’t see where one layout switches to the next, and a section can look its most awkward just before a switch. Choosing which sizes to open is its own job, covered in the guide to which screen sizes to use when reviewing a website.
Breakpoints respond to the browser window, not the monitor. A visitor with a 1920-wide screen can keep the browser window much narrower than that, and the page follows the window. The widths are also measured in CSS pixels, the units a page lays out in, which are not the same as the physical pixels printed on a device spec sheet. MDN explains the ratio between the two as devicePixelRatio.
How to Spot a Transition That Isn’t Working
You can see a transition yourself without any special tools. Open the page in an ordinary desktop browser and slowly narrow the window. Watch each section as it approaches a switch, and note where text gets cramped or columns squeeze before they stack. Take a screenshot of the awkward moment and note the page and section. You can report the problem without knowing the exact width.
Online Website Previewer helps with the other half of the job. It shows the live page side by side at three starter sizes, 1920 by 1080, 820 by 1180, and 390 by 844 in CSS pixels. Custom sizes aren’t offered, so the previewer shows you which layout each size gets, not where the switch between them happens.
Use the two together. The previewer helps you spot problems at those three sizes, and the narrowing window can reveal problems between them. If you have no window to drag, for example on a tablet, ask the team for screenshots just before and just after the switch.
Should Popular Device Sizes Be the Breakpoints?
It is tempting to take the most common screen sizes and set the breakpoints there. In Statcounter’s worldwide tables for October 2026, the most common phone size was 414 by 896, with a 12.67% share. The top desktop size was 1920 by 1080 at 27.82%, and the top tablet size was 1280 by 800 at 7.96%. Statcounter records the screen resolution on each page view, so these describe whole screens, not browser windows. Many of the phone figures match the sizes pages lay out at, such as 390 by 844, rather than the physical resolution on a spec sheet.
Those figures are useful for deciding which sizes to test. They make poor breakpoints, for three reasons.
No size dominates. Even the most common phone size had a share under 13% that month. Each layout has to work across a range of widths anyway, so tuning a switch to one popular device gains little.
Device sizes keep changing. web.dev’s guidance on media queries recommends choosing breakpoints based on your content rather than popular device sizes, because device sizes change with every technology release cycle.
A popular device width doesn’t tell you when the content needs a new layout. The common phone widths in Statcounter’s table run from 360 to 414. None of the frameworks and website builders listed below switches layouts below about 480 pixels, so all of those phones get the same smallest layout anyway. Use those widths to inspect the page, then ask whether the content needs a different arrangement before or after them.
Nielsen Norman Group does suggest analyzing the devices your own audience uses as a starting point. The two views fit together. Use audience data to decide which widths to check, and let the content decide where the layout should change.
Do Frameworks Agree on Breakpoints?
Most teams don’t invent responsive breakpoints from scratch. They start from the defaults in the framework or website builder they use. The short answer is that those defaults cluster around similar widths but don’t agree exactly, so there is no single standard to hold a team to.
You don’t need to memorize the list below. Ask your team which tool the site uses, then find it in the list. These are the documented defaults when we checked in November 2026, in pixels unless noted:
- Bootstrap 5.3: 576, 768, 992, 1200, and 1400.
- Tailwind CSS v4: 640, 768, 1024, 1280, and 1536 (set in rem units).
- Foundation 6: 640 and 1024 by default.
- MUI: 600, 900, 1200, and 1536.
- Material Design 3: width classes that change at 600, 840, 1200, and 1600 (in dp rather than pixels).
- Bulma 1.0: tablet from 769, desktop from 1024, then 1216 and 1408.
- Webflow: tablet at 991 and below, mobile landscape at 767 and below, mobile portrait at 479 and below, plus optional larger breakpoints.
- Wix Studio: mobile from 320 to 750, tablet from 751 to 1000, desktop from 1001.
- Elementor: mobile at 767 and below, tablet at 1024 and below.
- WordPress 7.1: for block themes, mobile styles apply at 480 and below and tablet styles above 480 up to 782, according to WordPress’s responsive styles documentation. Themes can change both, and classic themes set their own breakpoints.
The numbers cluster. 768 is the most shared, 1024 comes next, about 1200 often marks a large desktop layout, and 600 is common in Google’s Material world. Squarespace doesn’t publish a pixel value for its mobile layout, so don’t assume one.
The edges differ, and that changes what a visitor sees. Bulma treats 768 as mobile, while Bootstrap and Tailwind treat it as the start of the tablet layout. Wix says an iPad Pro at 1024 sees the Wix Studio desktop layout, while 1024 is still tablet in Elementor’s defaults. Bootstrap itself describes its breakpoints as representative of a subset of common sizes that don’t target every device.
So a framework default tells you the team’s starting convention. It doesn’t prove that a switch at that width suits your page.
What Should Decide Where the Layout Changes
MDN and web.dev both point to the content. MDN recommends changing the design at the point where the content starts to look bad. Examples include lines of text growing too long or a box getting so squashed that it holds two words per line. web.dev’s older responsive design basics suggests a column of about 70 to 80 characters per line, roughly 8 to 10 words in English. It recommends considering a breakpoint whenever a text block grows past about 10 words per line.
Other factors shape the decision too:
- The main task. A pricing comparison, a booking form, or a product grid needs enough room to stay usable. When it no longer has that room, the layout should change.
- Practical limits. Nielsen Norman Group observes that designers usually accommodate only two or three breakpoints in practice.
- The platform. Builders like Webflow, Wix Studio, and Elementor ship their own defaults, and WordPress 7.1 lets themes set their own values to match a design system.
- An accessibility floor. The W3C’s Reflow success criterion expects content to work at a width equivalent to 320 CSS pixels without scrolling in two directions. That is the same as a 1280-wide window zoomed to 400%. Ask the team to show how the page behaves at that width.
Some cards or other page elements can respond to the space around them rather than the whole window, using container queries. If one changes independently of the rest of the page, ask the team to show that its content stays readable and usable across that change.
Ask for an Outcome, Not a Number
You rarely need to name a pixel value in your feedback. Describe what goes wrong and what the section should achieve, and let the team decide where the breakpoint belongs.
A useful note has four parts: the section, the visible problem, the effect on the task, and the outcome you want. For example: “Pricing page, plan comparison, browser window narrowed from desktop (screenshot attached): the three plan columns get cramped just before they stack, so the prices are hard to compare. Please show a revised transition that keeps the prices readable and the plans comparable.”
For more on writing notes like that, see how to give useful feedback on a website design. If the layout jumps between a few fixed versions rather than adjusting gradually, the responsive vs adaptive guide explains what that can mean and what to ask.
