CSS Container Queries in 2026: Stop Writing Media Queries for Every Component

You have a beautiful card component. It works perfectly in your three-column grid. Then a designer drops it into a narrow sidebar — and it breaks. You add a media query. Then another. Six months later your stylesheet has 40 breakpoints and nobody knows which one is doing what anymore. There is a better way. And in 2026, it is fully supported in every major browser.

What Are CSS Container Queries?

Media queries have been around since 2010 and they do one thing: they look at the viewport (screen) width and apply styles accordingly. That works great for page-level layouts. But it falls apart the moment you try to build a component that can live in different places on the same page.

Container queries solve this. Instead of asking "how wide is the screen?", they ask "how wide is this element's parent container?". Your component becomes context-aware. Drop it in a sidebar — it knows it is narrow. Drop it in a hero section — it knows it has room. No JavaScript. No class toggling. Pure CSS.

Think of it like this: media queries are about the room you are in. Container queries are about the box you are sitting in.

Browser Support in 2026: Fully Green

Container size queries have been supported in Chrome, Firefox, and Safari since 2023. You are completely safe to use them in production today with zero polyfills or fallbacks needed. Container style queries are also landing in Firefox in 2026 as part of the Interop 2026 initiative — completing full cross-browser coverage.

The Basic Syntax — Learn It in 5 Minutes

There are just two steps. First, declare which element is the container. Then write styles that respond to it from inside.

/* Step 1: Declare the container */
.card-wrapper {
  container-type: inline-size;  /* respond to width */
  container-name: card;         /* optional name */
}

/* Step 2: Write styles inside @container */
@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 120px 1fr;
    gap: 1.5rem;
  }
}

When .card-wrapper is narrower than 400px, the card stacks vertically. When it is 400px or wider, it becomes a two-column grid. The viewport width does not matter at all. The card reacts to where it lives — not what screen the user has.

Real-World Example: A Product Card That Works Everywhere

Here is a complete product card that handles all three common contexts — full-width, medium grid, and narrow sidebar — with a single stylesheet and zero JavaScript.

/* The HTML */
<div class="product-container">
  <div class="product-card">
    <img src="product.jpg" alt="Product photo" />
    <div class="product-info">
      <h3>Product Name</h3>
      <p>Short description here</p>
      <span class="price">$49.99</span>
      <button>Add to cart</button>
    </div>
  </div>
</div>

/* Container setup */
.product-container {
  container-type: inline-size;
}

/* Default: narrow / sidebar layout */
.product-card {
  display: flex;
  flex-direction: column;
  border: 1px solid #e5e7eb;
  border-radius: 10px;
  overflow: hidden;
}

.product-card img {
  width: 100%;
  aspect-ratio: 16/9;
  object-fit: cover;
}

.product-info {
  padding: 1rem;
}

/* Medium: side-by-side layout (container >= 360px) */
@container (min-width: 360px) {
  .product-card {
    flex-direction: row;
    align-items: center;
  }

  .product-card img {
    width: 140px;
    min-height: 140px;
    flex-shrink: 0;
    aspect-ratio: 1/1;
  }
}

/* Wide: full featured layout (container >= 600px) */
@container (min-width: 600px) {
  .product-card {
    display: grid;
    grid-template-columns: 260px 1fr;
  }

  .product-card img {
    width: 100%;
    aspect-ratio: 4/3;
  }

  .product-info {
    padding: 1.5rem 2rem;
    display: flex;
    flex-direction: column;
    justify-content: center;
  }
}

Drop this card anywhere on your page — homepage hero, sidebar, search results, related posts — and it figures out its own layout every time. You write it once. It just works.

Container Query Units: The Feature Everyone Misses

When you declare a container, you also unlock special units: cqi, cqw, cqb, cqh, cqmin, and cqmax. These work exactly like vw and vh — but relative to the container's dimensions instead of the screen.

/* Font size that scales with the CONTAINER, not the viewport */
.card-title {
  font-size: clamp(1rem, 5cqi, 2rem);
  /* cqi = 1% of the container's inline (width) size */
}

.card-image {
  width: 40cqw;  /* 40% of the container width */
}

.icon {
  width: clamp(24px, 8cqi, 64px);
}

This means your typography and spacing can scale fluidly inside a component — exactly proportional to the space it has. A heading in a wide container reads large and confident. The same heading in a sidebar is smaller and compact. Same CSS file. Zero extra work.

Container Queries vs Media Queries: When to Use Which

They are not enemies — use both. The key is knowing which tool belongs where.

Simple rule: if you are styling the page skeleton, use a media query. If you are styling a component, use a container query.

Style Queries — The Next Level (New in 2026)

Size queries respond to how wide a container is. Style queries respond to the values of CSS custom properties on the container. This is landing in Firefox in 2026 and enables a powerful new theming pattern:

.theme-wrapper {
  container-type: style;
  --theme: dark;
}

@container style(--theme: dark) {
  .card {
    background: #1e293b;
    color: #f1f5f9;
    border-color: #334155;
  }
}

/* Switch an entire section to dark just by changing one variable */
.sidebar {
  --theme: dark;
}

Style queries are already supported in Chrome and Safari. Firefox support arrives mid-2026. Use them as progressive enhancement for now — not as a hard dependency.

Why This Matters for Your Codebase

One real production project deleted 600 lines of CSS after switching to container queries — not from a big rewrite, just by removing the media query overrides that had been fighting each other for years. When components own their own responsive logic, your stylesheet becomes dramatically easier to read, maintain, and hand off to a team.

Combined with the other CSS upgrades that landed in 2025–2026 — native nesting, the :has() selector, scroll-driven animations, and cascade layers — CSS in 2026 is a genuine architecture tool. Developers who treat it that way are writing less code and deleting more of the old stuff.

Key Takeaways

• Container queries respond to parent width, not screen width

• Fully supported in Chrome, Firefox, and Safari — use in production today

• Declare with container-type: inline-size, then query with @container

• Container units like cqi and cqw scale relative to the component, not the viewport

• Style queries let you query CSS custom property values — new in 2026

• Do not replace media queries — use both tools for their intended purpose