Ten years ago, "responsive design" meant making sure your website didn't break on phones.
You had desktop (roughly 1200px wide), tablets (roughly 768px), and mobile (roughly 375px). Build for those three breakpoints and you covered most people.
In 2026, that model doesn't work anymore.
The problem with the old breakpoints
People now browse on foldable phones that switch between narrow and wide mid-session. Tablets in both portrait and landscape. Ultrawide monitors that are 3440px across. Laptop screens that range from 1366px to 1920px. Desktop monitors in 4K.
The old approach - desktop, tablet, mobile - doesn't account for the range anymore. A layout that looks good at 1920px often looks wrong at 2560px. A design optimised for a 375px phone breaks on a 280px smartwatch browser or a 430px foldable in portrait mode.
Here's what we do instead when we build web applications and Next.js sites.
Fluid layouts instead of fixed breakpoints
Rather than designing three layouts - one for each breakpoint - we design layouts that scale proportionally.
This means using relative units (rem, em, percentages, viewport units) instead of fixed pixel values. It means using CSS features like clamp() to set minimum and maximum sizes with fluid scaling in between. It means building layouts that adapt continuously rather than snapping between predefined states.
Example: instead of setting a heading to 48px on desktop and 24px on mobile, we use something like `clamp(1.5rem, 4vw, 3rem)`. The heading scales smoothly between 24px and 48px based on viewport width, without needing a breakpoint.
Breakpoints for layout changes, not sizes
We still use breakpoints - but only for structural changes, not for resizing elements.
A sidebar might stack below the main content on narrow screens and sit beside it on wider screens. That's a layout shift that needs a breakpoint. But the text size, spacing, and proportions within each section scale fluidly.
This approach means fewer breakpoints to maintain, and layouts that don't break in the gaps between breakpoints.
Designing for foldables specifically
Foldable phones present a new problem: the screen width changes without a page reload.
A user opens a site on the narrow outer screen (around 280-380px), then unfolds the device to the inner screen (around 600-800px). The layout needs to respond immediately.
This works if you've built fluid layouts. It breaks if you've hard-coded assumptions about screen size into your JavaScript or relied on breakpoints that don't cover the foldable range.
We test layouts on Samsung Galaxy Fold and similar devices to make sure the transition is smooth.
Ultrawide monitors and how to handle them
At the other end of the spectrum, ultrawide monitors (2560px and above) expose a different issue: content that stretches too wide becomes hard to read.
The solution is to set a maximum content width - usually around 1400-1600px - and center it. Beyond that width, the layout doesn't expand further; it just adds whitespace on the sides.
This keeps text readable and the interface usable, even on very large displays.
What this means in practice
For most small business websites, you don't need to overthink this. A well-built responsive layout will handle the range without custom code for every device.
For custom applications where the interface is more complex, it's worth testing across the full range - especially if your users are likely to be on tablets, foldables, or large monitors.
If you're building something new or reworking an existing site and you want to make sure it holds up across the full range of devices people actually use, talk to us about how we approach responsive design in 2026.