Responsive web design is the practice of building one site whose layout, navigation, and content adapt to the visitor’s viewport. A breakpoint is a viewport width where those rules change: a horizontal menu becomes a compact menu, three columns become one, or a table becomes a list.
This page is about layout behaviour and how to test it. It is not a guide to loading metrics. Those are covered in Core Web Vitals.
Fluid layout, then breakpoints
Start with flexible columns, images that do not overflow, and text that can wrap. Breakpoints then handle the moments when flexibility is not enough. A common set is a small phone width, a large phone or small tablet, a laptop, and a wide desktop. Copying a framework’s default numbers is fine only if your content actually breaks there.
Choose a breakpoint when:
- A line of text becomes too long to read comfortably
- Tap targets collide
- A row of cards leaves an awkward gap
- Navigation no longer fits on one line
- A data table requires horizontal scrolling that hides the row label
Do not add a breakpoint only because a particular phone model exists. Viewports overlap. Design for ranges.
What should change, besides column count
- Navigation. A full menu can become a button that opens a panel. The panel must be reachable by keyboard and easy to close.
- Priority. The first screen on a phone should still contain the page’s purpose and primary action, not only a cropped hero image.
- Tables and galleries. Stack, scroll with a visible cue, or show fewer columns. A table cut off with no hint is a broken page.
- Spacing. Desktop padding is often too large on a phone and too tight if you only shrink the font.
Type size should remain readable. Pinch-zoom should not be disabled to hide an overflow.
Breakpoint testing pass
- List the widths where layout rules change
- Check just below and just above each width
- Complete one task on a phone-sized viewport
- Repeat on a laptop width
- Fix overflow, overlap, and unreachable actions
How to test
Use browser device mode for a first pass, then a real phone. Device mode misses font rendering, the browser chrome that eats height, and touch delay. Check at least:
- A narrow width around 360px
- A width just under your first breakpoint and 1px above it
- A tablet portrait width
- A 1280px laptop
- A very wide window, so lines and images do not stretch without limit
Look for horizontal scroll on the page itself. That almost always means an image, a long word, or a fixed-width element escaped its column. Image sizing is covered in website images.
A practical example
A three-column service grid is comfortable at 1100px. At 700px the centre column is readable but the buttons wrap onto the photo. The team adds one breakpoint at 760px that stacks the cards and moves the action under the text. They check 759 and 761. They also shorten the desktop menu labels that collided at 900px, instead of inventing a second menu only for that gap.
Key takeaways
- Let the layout flex, and add breakpoints where the content breaks.
- Test both sides of each breakpoint, on a phone and a laptop.
- Navigation, tables, and primary actions need an explicit small-screen design.
- A resized desktop window is a start, not the sign-off.
FAQ
Is a separate mobile site better?
Almost never for a company website. Two sites drift apart. Responsive design keeps one set of pages with shared content.
Should we design mobile or desktop first?
Either can work if both are tested. Mobile-first helps you decide what must appear when space is scarce. Desktop-first helps complex comparisons. Do not ship the one you designed and hope the other collapses cleanly.
Do breakpoints affect accessibility?
They can. A menu that only opens on hover, or a link that sits off-screen, fails people using a keyboard or a phone. Pair this check with website accessibility.