
Responsive design in 2026: beyond mobile-first
Container queries, fluid type, input types and user preferences: how modern responsive design works today and what it adds on top of mobile-first layouts.
In short: Mobile-first is still a good starting point, but it covers only part of responsive design. Modern interfaces respond to the space a component actually has (container queries), to the input type (touch, mouse, keyboard) and to user preferences such as dark mode or reduced motion. The CSS tools for all of this are available in every current browser and need no hacks.
What mobile-first gets right, and where it stops
Mobile-first means designing the layout for small screens first and then extending it for larger ones. It forces you to focus on what matters and usually leads to leaner code. None of that has changed.
The assumption behind it, though, was that devices sort neatly by screen width: phone, tablet, desktop. That split fits less and less. Foldable phones change size while in use, tablets are used with keyboard and trackpad, windows on large monitors are often narrow, and the same component may sit in a wide main column on one page and a tight sidebar on another.
Container queries: components that know their space
Media queries ask about the viewport width. Container queries ask about the width of the surrounding element. A product card can then adapt to the space it really has, whether it sits in a grid, a carousel or a sidebar. All major browsers have supported container queries since 2023.
For teams with a design system, this is a big step forward. Components become truly reusable because they no longer need to know which page they end up on. Global breakpoints handle the page layout; components handle their own internals.
Fluid typography and spacing
Instead of changing font sizes in jumps at fixed breakpoints, the CSS clamp() function scales them smoothly between a minimum and a maximum. The same works for spacing. The result looks balanced at every width and needs fewer media queries.
One caveat: build those values on rem, so users who set a larger default font in their browser actually get it. Scaling purely with viewport units would override that setting.
Input types and user preferences
Touch, mouse and keyboard
The pointer and hover media features tell you whether a device can point precisely and hover. On touch devices, controls need large enough hit areas, and content must never be reachable only on hover. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels; larger targets are better for comfortable touch use. Keyboard users need visible focus states on every device.
Color scheme, motion and contrast
prefers-color-scheme lets an interface follow the system's light or dark setting, prefers-reduced-motion respects a wish for less animation, and prefers-contrast signals that someone needs more contrast. These preferences belong in modern responsive design as much as screen width. Handle them well and you also meet many requirements for web accessibility.
Technical details that often get missed
Viewport height on mobile
The classic 100vh unit is unreliable on phones because the address bar slides in and out. The newer dvh, svh and lvh units solve this and are widely supported.
Responsive images
With srcset and sizes the browser loads the right image size, and the picture element lets you serve different images by format or crop. That saves mobile data and noticeably improves load time.
Test on real devices
Browser device emulation is useful but no substitute for real hardware. Touch behavior, on-screen keyboards and performance on a mid-range phone only show up there. Our post on mobile UX patterns covers which interaction patterns work well on mobile.
Frequently asked questions (FAQ)
Does mobile-first still make sense in 2026?
Yes, as a way of working on layout and content priority. Add container queries for components and media features for input type and user preferences. On its own, mobile-first no longer covers today's range of devices.
Can we use container queries safely now?
For current browsers, yes. All major browsers have supported them since 2023. If your audience demonstrably uses very old browsers, plan a simple fallback layout that works without them.
How many breakpoints does a website need?
Fewer than it used to. With fluid type and container queries, many projects manage with two or three global breakpoints for page layout. Place them where your content breaks, not at specific device models.
Does a business website need dark mode?
It is not mandatory. Many people keep their system in dark mode permanently, though, and a site that responds to it feels well cared for. If you offer it, design it properly, with sufficient contrast in both variants.
Conclusion
Responsive design in 2026 means responding to the real context: available space, input type and user preferences. The tools are in every current browser, and they usually make your code simpler rather than more complicated. If you are planning a website or web application that works well on every device, talk to us about web development.
Related posts
- Design Systems: Why Every Development Team Needs One
What a design system includes, when it pays off and how tokens, components and documentation help design and development ship faster and more consistently.
- Mobile UX Patterns That Convert: What Good Apps Do Differently
Which mobile UX patterns lead to more sign-ups and purchases in apps: thumb zone, onboarding, forms, permission requests and loading states in detail.
- From Wireframe to Pixel-Perfect: The UI Design Process
How an idea becomes a buildable UI design: requirements, wireframes, prototype, visual design, handoff to development and a shared review in the browser.
- Dark mode implementation: CSS variables, system settings, design
How to build dark mode properly: colour tokens as CSS variables, prefers-color-scheme, a toggle without flashing, contrast, images and common mistakes.