Container Queries vs. Responsive Design: What I'd Actually Use

That Dashboard Card I Kept Fighting

Last spring, I spent a full afternoon wrestling with a dashboard card. It had to fit a narrow sidebar, a medium column, and a full-width hero. With media queries, I'd write breakpoints for the viewport, but the card's container width depended on the grid, not the browser window. So I'd end up with overrides like @media (min-width: 900px) { .card { display: flex; } } and hope it didn't break on some odd screen. It did, of course.

That's the core tension: responsive design looks at the viewport, but components live inside containers. Container queries (@container) let a component respond to its own parent's size, not the whole window. It's not a new concept, but it's finally widely supported. According to MDN, container queries have been Baseline Widely available since February 2023. That changes things.

In this comparison, I'll walk through flexibility, performance, accessibility, and browser support. Then I'll tell you what I'd ship today.

Four Things That Actually Matter

Flexibility. Media queries are a blunt hammer. You set breakpoints at 375px, 768px, 1024px, and hope your components behave in every context. But a card in a sidebar and the same card in a main column share the same viewport, so you can't tune them independently. Container queries? They're precise. That same card can stack vertically in a 250px sidebar and switch to a horizontal layout in a 600px column, without a single viewport hack. That's the kind of modularity that saves hours.

Performance. Both approaches are lightweight when done right. Media queries add no bytes, but container queries can trigger extra layout recalculations because the browser tracks container sizes. In practice, I've never seen a real-world page suffer from this unless someone over-nests containers—like ten levels deep, which you shouldn't do. The bigger performance wins come from images and fonts: set width and height to avoid layout shift (MDN recommends this), use srcset with sizes to serve the right resolution, and lazy-load with loading="lazy". That's where you'll see the real Core Web Vitals gains.

Accessibility. This is where container queries shine, but only if you use them thoughtfully. WCAG 2.1 SC 1.4.10 (Reflow) says content should be readable without two-dimensional scrolling at 320px viewport width—that's a viewport-based rule. Media queries handle that well. But container queries let components reflow based on their own space, which is often more robust for nested layouts. Both approaches must respect prefers-reduced-motion and prefers-color-scheme. And don't forget touch targets: WCAG 2.2 requires at least 24x24 CSS pixels, but Apple and Google recommend 44x44 and 48x48 respectively. So make your buttons big enough, regardless of your layout technique.

Browser support. This is the only real sticking point. Media queries work everywhere. Container queries are Baseline since Feb 2023, meaning all major browsers support them. As of July 2026, Chrome has 68.22% market share, Safari 16.47%, and Edge 5.37% (StatCounter). That's over 90% combined. If you need to support ancient browsers, you can use a polyfill, but honestly, it's time to move forward. The web is mobile-first—52.57% of traffic is mobile (StatCounter)—and Google uses mobile-first indexing. So you need a strategy that works on small screens, and container queries excel there.

Side-by-Side: The Quick Verdict

So which wins? For a simple marketing site with a few layouts, responsive design is still fine. But for complex, component-driven interfaces—dashboards, design systems, e-commerce—container queries are the clear winner. They reduce the need for viewport hacks and make components truly reusable. I'm not saying abandon media queries entirely; you'll still use them for whole-page layouts. But the future is container-first.

Who Should Use Which

If you're building a brochure site, a blog, or a landing page with a single column and a sidebar, responsive design is all you need. It's simple, proven, and works everywhere. But if you're building a design system with components that appear in multiple contexts—like a card that lives in a sidebar, a grid, and a modal—you need container queries. The same component can adapt without you writing a dozen media query overrides. Container queries also pair beautifully with modern CSS features like :has() and subgrid, which are also Baseline Widely available (MDN). For example, you can use :has() to style a section based on whether it contains a featured child, and container queries to change the layout of that section based on its width. This is the kind of power that makes responsive design feel clunky.

Let me give you a concrete example: a product card. In a sidebar, you want it stacked vertically—image on top, title, price, button below. In a full-width section, you want the image on the left and the text on the right. With media queries, you'd have to know the viewport width at which the sidebar becomes that wide—but the sidebar's width depends on the layout, not the viewport. Container queries solve this: you write one rule for when the container is narrow, another for when it's wide. That's a huge time-saver and makes your CSS more maintainable.

Accessibility is another reason to go container-first. WCAG 2.1 SC 1.4.4 requires text to be resizable up to 200% without loss of content. With container queries, you can ensure that when a container shrinks, the text doesn't overflow—because the component reflows based on its own size. You can also use clamp() for fluid type, like font-size: clamp(1rem, 2.5vw, 2rem), but beware: viewport units alone prevent zooming (MDN). So combine them with rem as shown. Container queries don't replace this; they complement it.

Performance-wise, both approaches can fail if you ignore Core Web Vitals. LCP should be 2.5 seconds or less, INP 200ms or less, and CLS 0.1 or less (web.dev). To hit those, you need to optimize images, use font-display: swap to avoid invisible text, and reserve space for images with width and height attributes. Container queries don't inherently hurt these; just be mindful not to over-nest containers, which could increase layout work. But modern browsers handle it well.

My Take: Start Container-First

Here's what I'd actually do: start every new project with container queries as your primary layout tool for components, and use media queries for the page-level grid. If you're working on a legacy site, gradually refactor the most complex components to use @container. The browser support is there—it's been Baseline since February 2023, and as of July 2026, Chrome and Safari alone cover over 84% of browsers. Don't let fear of older browsers hold you back. For the rare edge case, you can provide a fallback using media queries, but don't design with a fallback mindset. The web is mobile-first, and container queries are the best way to make components that truly respond to their environment. So go ahead, embrace @container. Your future self will thank you when you don't have to write that 400th media query.

Sources

• MDN Web Docs - Responsive design: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
• MDN Web Docs - Container queries: https://developer.mozilla.org/en-US/docs/Web/CSS/@container
• W3C WCAG 2.1 Understanding Reflow: https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
• web.dev - Web Vitals: https://web.dev/articles/vitals
• StatCounter Global Stats - Platform: https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet
• StatCounter Global Stats - Browser: https://gs.statcounter.com/browser-market-share