Responsive CSS in 2026: A Practical Guide for Real Sites

Most “responsive design” problems I get called about aren’t about breakpoints. They’re about layout decisions that were fine in 2015 and quietly stopped working. Here’s what actually holds up in 2026, with the code I use.

Stop guessing at breakpoints

The old workflow was: design at 320, 768, 1024, 1440, then write a media query for each. That works until a client adds a sidebar, or a card gets dropped into a narrow column, and suddenly the component is broken at a width nobody tested.

Container queries fixed this. A component can now respond to the space it’s in, not the size of the viewport. As of 2026 every current browser supports them, so there’s no reason to keep avoiding them.

.card-grid {
 container-type: inline-size;
 display: grid;
 gap: 1rem;
}

.card {
 display: grid;
 gap: 0.75rem;
}

@container (min-width: 34rem) {
 .card {
 grid-template-columns: 12rem 1fr;
 align-items: start;
 }
}

That card now goes horizontal whenever its container is wide enough, whether that’s a full-width page, a two-thirds column, or a sidebar. No viewport math, no duplicated rules.

Fluid type without the headache

Hand-setting font sizes at every breakpoint is busywork. clamp() does the same job in one line, and it’s been safe to use for years now.

h1 {
 font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem);
 line-height: 1.15;
}

body {
 font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem);
}

The middle value is the fluid part. The outer values are your floor and ceiling, so text never gets unreadably small on a phone or absurdly large on a 4K monitor. Two things people get wrong here: they clamp the line-height too (don’t, keep it unitless), and they use viewport units for anything that affects vertical rhythm, which causes the “text jumps when the mobile URL bar hides” bug.

Layout: grid first, flexbox for the small stuff

My rule is simple. If I’m placing things in two dimensions, it’s grid. If I’m spacing a row of buttons or aligning an icon next to a label, it’s flexbox. Mixing them up is where most of the weird alignment bugs come from.

.page {
 display: grid;
 grid-template-columns:
 minmax(1rem, 1fr)
 minmax(0, 72rem)
 minmax(1rem, 1fr);
}

.page > * {
 grid-column: 2;
}

.page > .full-bleed {
 grid-column: 1 / -1;
}

That’s a centered content column with gutters, plus an escape hatch for full-width sections. No wrapper divs, no negative margins. The minmax(0, 72rem) matters: without the zero minimum, a wide table or long unbroken string will blow out the whole grid.

The stuff that still breaks on real phones

• Images without dimensions. Always set width and height attributes on <img> so the browser reserves space. Layout shift is a ranking and a usability problem.
• Fixed 100vh. On mobile browsers the viewport changes as the toolbar shows and hides. Use 100dvh or, better, don’t tie critical layout to viewport height at all.
• Hover-only interactions. If a menu only opens on hover, it’s broken on a touchscreen. Test with a real device, not just a resized desktop window.
• Tap targets under 44px. Apple and Google both publish minimums. Small links in footers are the usual offender.
• Tables. A five-column data table will never be pleasant on a phone. Decide up front whether it scrolls horizontally, collapses to cards, or gets cut down.

Test at the widths that matter, not the ones that look nice

I keep three devices on my desk and a browser window I drag around constantly. The drag test catches more than any preset device list, because real breakage happens at 431px, not 430px. If you want a fast check, open devtools, set the responsive mode, and slowly drag from 320 to 1600 while watching for anything that jumps, overlaps, or clips.

For anything client-facing, I also check on an actual older iPhone and an Android device, because Safari on iOS still has quirks with form controls, sticky positioning, and safe-area insets that you won’t see in a desktop emulator.

Where this fits into a bigger site

Responsive CSS is one layer. If the underlying markup is a mess of nested divs and inline styles, no amount of media queries will make it maintainable. That’s usually the point where a rebuild makes more sense than another round of patches, and it’s the kind of work I do as a Long Island web design project. Local businesses here tend to have the same problem: a site built five years ago by someone who’s no longer around, with a mobile experience that was an afterthought.

Quick checklist

• Container queries for components, media queries for page-level layout.
• clamp() for type and spacing, unitless line-heights.
• Grid for two-dimensional layout, flexbox for one-dimensional.
• Explicit image dimensions, dvh instead of vh.
• Real device testing, not just emulators.

FAQ

Do I still need media queries if I use container queries?

Yes, but far fewer. Container queries handle components that get reused in different widths. Media queries are still the right tool for page-level changes like switching a sidebar from beside the content to below it.

Is clamp() safe for accessibility?

It’s safe as long as your minimum size stays readable and you don’t lock text down so hard that browser zoom stops working. Never use vw alone for font size, because it ignores the user’s text-size preference.

How many breakpoints should a site have?

As few as the design actually needs. I usually start with zero and add one only when something visibly breaks. A typical marketing site ends up with two or three, not the eight or nine I see in older stylesheets.