CSS Container Queries: Responsive Layouts Based on the Container, Not the Screen

For years, responsive design in CSS has almost always meant reacting to the width of the browser window through media queries. That works well for a page's overall layout, but it shows its limits when building reusable components: a card, a sidebar widget, anything that needs to adapt to the space it is actually given, not to the user's screen. CSS Container Queries solve exactly this problem, and by 2026 they are a mature technology supported by every major modern browser.

This article covers what they are, how to use them in practice, and when they work alongside media queries rather than replacing them.

What container queries are and why they matter

A container query applies CSS rules to an element based on the size (or style) of its containing element, instead of the viewport. In practice: put the same card in a wide column and in a narrow sidebar, and it can automatically change layout, font size or the arrangement of its content depending on the real space around it, regardless of the overall screen width.

This is what makes true component-level design possible: the same HTML/CSS block can be reused in different places on a site and will behave intelligently wherever it ends up.

Turning an element into a container: container-type and container-name

For an element to be "queried" by its children, it must first be declared as a query container using the container-type property:

• inline-size: the most common case, enabling queries based only on the container's inline dimension (usually its width).
• size: enables queries on both width and height, but requires the container's height to be explicitly defined, otherwise the content may collapse.
• normal: the default value; the element is not a size query container but can still be used for name-only or style queries.

A minimal example:

.post {
  container-type: inline-size;
}

When a page has several nested containers, it helps to distinguish them with container-name, so later rules know which container they refer to:

.post {
  container-type: inline-size;
  container-name: article;
}

Both properties can also be written with the shorthand syntax container: name / type;, for example container: article / inline-size;.

The @container syntax in practice

Once a container is defined, rules are written with the @container at-rule, whose form closely mirrors @media:

@container (width > 700px) {
  .card h2 {
    font-size: 2em;
  }
}

To target one specific container among several nested ones, add its name before the condition:

@container article (width > 700px) {
  .card { font-size: 2em; }
}

A common real-world case is a card that stacks its title and image when space is tight (say, inside a sidebar) and places them side by side when the container is wider (say, in a page's main column): the exact same HTML markup changes behaviour automatically, with no extra classes or JavaScript needed.

Container-relative length units

When an element is a size or inline-size container, dedicated length units become available, designed to size fonts, spacing or elements proportionally to the container instead of the viewport:

• cqw: 1% of the container's width.
• cqh: 1% of the container's height.
• cqi: 1% of the container's inline size (usually its width, in horizontal writing modes).
• cqb: 1% of the container's block size (usually its height).
• cqmin: the smaller of cqi and cqb.
• cqmax: the larger of cqi and cqb.

A typical example is a heading that scales fluidly with the available space, combining cq units with clamp() or max():

.card h2 {
  font-size: max(1.5em, 1.23em + 2cqi);
}

If an element has no valid ancestor container, these units safely fall back to their small-viewport equivalents, so the layout never breaks.

Container style queries: a step beyond size

Alongside size queries, the specification also introduces container style queries, which apply rules based on the container's style (for example, the value of a CSS custom property), not just its dimensions: @container style(--theme: dark) { ... }. This is a newer feature and, unlike size queries which are now stable everywhere, still has partial support: fully available in Firefox, with only partial support in Chrome, Edge and Safari. For production use today it's therefore best to stick to size queries and treat style queries as an emerging technique to test carefully.

Browser support in 2026

Size-based container queries (built on container-type: size or inline-size) are now a solid, well-established technology: supported by Chrome and Edge since version 106, Safari since version 16, and Firefox since version 110, along with their respective mobile versions (Safari on iOS, Chrome for Android, Samsung Internet, Firefox for Android). Global support now exceeds 94% of users, missing only on legacy or niche browsers such as Internet Explorer, Opera Mini, or a handful of regional Android browsers (UC Browser, QQ Browser, Baidu Browser). For most modern web projects, size-based container queries can be used with little concern, optionally pairing them with a flexbox or grid fallback for the remaining audience on very old browsers.

Container queries or media queries: what to use when

The two techniques aren't competing; they solve different problems:

• Media queries remain the right choice for a page's overall layout: number of columns, whether a menu is visible, how the whole grid behaves based on the viewport.
• Container queries are the right choice for individual components that need to be reusable and "aware" of the space they're placed in: cards, widgets, design-system blocks, sidebar elements.

In real projects the two coexist comfortably: media queries define the page's overall scaffolding, while container queries fine-tune the behaviour of the components inside it. This shift in perspective is especially useful for teams working with design systems and component libraries, where the same interface block has to work well no matter where it's placed.

Conclusion

CSS Container Queries fill a long-standing gap in responsive CSS: letting a component reason about its own real space, not just the browser window. With solid browser support now in place for size queries, it's a good time to start introducing them into your projects, perhaps beginning with a single component (a card, an info box) before extending the approach to an entire design system. Style queries, still gaining adoption, are worth keeping an eye on for the near future.

Official sources

• MDN Web Docs – CSS container queries
• MDN Web Docs – Using container size and style queries
• Can I use – CSS Container Queries (Size)
• Can I use – CSS Container Style Queries