How to Inspect CSS Container Queries in Chrome

Container queries are the feature the web has wanted for nearly a decade. The ability for a component to respond to its own parent's size — rather than the viewport — is a genuine shift in how we build responsive layouts. Sidebar narrow? Cards adapt. Sidebar wide? Cards adapt again. All without a single @media query.

By 2026, container queries have broad browser support and are firmly out of "experimental" territory. But they're newer than media queries, which means a lot of developers still aren't sure how to debug them when things go wrong. Here's a practical walkthrough of inspecting container queries in Chrome — what the DevTools support looks like, how to catch the common bugs, and how to speed up the whole process.

What Are CSS Container Queries?

Before debugging, a quick refresher on what's actually happening under the hood.

Container queries vs media queries

A media query responds to viewport dimensions. A container query responds to the size of a declared parent. That means a component can live inside a narrow sidebar and a wide main column and render differently in each — same component, different behavior, without JavaScript and without knowing where it's placed.

Why they matter for responsive design

This solves a real problem. Before container queries, every "responsive component" was implicitly tied to the viewport. If you reused a card component in two different contexts, it would behave the same in both — even if one context was 300px wide and the other 900px. Container queries finally decouple the component from the viewport, which is how a lot of us have wanted CSS to work for a long time.

Setting Up a Container Query

To debug one, you need to have one. Here's the minimum viable setup.

Defining container-type and container-name

A container has to opt in. You do this by setting container-type on the parent element:

.card-wrapper {
  container-type: inline-size;
  container-name: card;
}

inline-size means the container watches its width. size watches both dimensions. normal is the default and disables container behavior.

The container-name is optional but useful — it lets you target a specific container when you have multiple nested ones.

Writing a basic @container rule

Once the container is set up, you query it:

@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

This says: "when the container named card is at least 400px wide, apply this layout." If you omit the name, the query applies to the nearest ancestor container.

Inspecting Container Queries in Chrome DevTools

Chrome DevTools added first-class support for container queries a while back, and it's gotten progressively better. Here's what's actually useful.

Finding containers in the Elements panel

Select any element that has container-type set. In the Styles pane, you'll see a small container badge next to the element. Click it — DevTools highlights the container's bounding box on the page, so you can see exactly what area the queries are reacting to.

If you don't see a badge, the element isn't a container. Which sounds obvious, but it's actually the most common "my container query isn't working" bug. More on that in a minute.

Reading the Container Queries badge

When you inspect an element that's inside a container query scope, DevTools shows a @container badge in the Styles pane next to any rule that came from a container query. Click it, and you jump to the rule definition with the container context highlighted. You also see the current container's size, so you know whether the rule should be active or not.

This is the fastest way to answer the question "why is this rule applying / not applying right now?"

Viewing active vs inactive rules

Rules from container queries that aren't currently matching are shown in the Styles pane with a struck-through or faded appearance, same as inactive media queries. Hover the rule and DevTools will tell you what condition would activate it. This is extremely helpful when you're iterating on breakpoints — you can see the entire cascade of container-conditional rules and understand which one will kick in next.

Debugging Common Container Query Issues

Now for the bugs you'll actually run into.

Container not being recognized

By far the most common issue: you wrote @container card (min-width: 400px) but nothing's applying. Usual culprit is that the container itself doesn't have container-type set, or it's set on the wrong element. A container has to be an ancestor of the queried element. If you set container-type on a sibling or on the child itself, the query won't resolve.

Check for the container badge. If it's not there, the container isn't registered.

Rules that never activate

Your container is registered, but the query rule never seems to kick in. Two common reasons:

1. The container isn't changing size the way you think. container-type: inline-size makes the container's own inline-size the basis for queries. If the container is set to width: 100%, its size depends on its parent, not on anything you can toggle directly. Resize the parent and watch what happens.
2. The query condition doesn't match. Double-check the breakpoint. DevTools' Container Queries badge shows you the container's current size — compare that to your min-width or max-width condition.

Nested container confusion

When you have multiple nested containers, an un-named @container rule applies to the nearest ancestor container. This is almost always not what you want in a nested scenario. Name your containers explicitly (container-name: card, container-name: sidebar) and reference them by name in queries. It removes an entire class of bugs.

Speeding Up Container Query Workflows

Using extensions for quick inspection

For day-to-day inspection — "is this element inside a container query scope?" — a lightweight CSS inspector is faster than opening DevTools. Tools like CSSpeek surface @container context in the hover panel, so you can see at a glance which rules are coming from container queries and which are normal.

Previewing breakpoints with resize tools

Container queries respond to container size, not viewport size. That means Chrome's responsive design mode (which resizes the viewport) doesn't directly help — you need to resize the container. A good workflow is to give the container an explicit width in DevTools (via the Styles pane), set it to different values, and watch the query rules flip on and off. Some teams add a temporary resize handle to container elements during development to make this easier.

Browser Support and Fallbacks

Container queries are supported in all major evergreen browsers at this point. If you still need to support older browsers (some enterprise contexts), the standard fallback is a @supports block:

@supports (container-type: inline-size) {
  /* container query styles */
}

And for the container query itself, wrap the intended styles in an @container rule but also provide a baseline that works without it. Progressive enhancement, basically.

Final Thoughts

Container queries are one of those features that take a little getting used to, but pay back the learning curve immediately. Once your components know their own context, responsive design stops being a series of viewport-based guesses and starts being real component logic.

Chrome DevTools handles container query debugging well, and lightweight CSS inspectors are starting to surface container context in hover views too. Install CSSpeek to see @container context alongside the rest of an element's computed styles. The tooling has caught up. Now it's just a matter of writing container queries with intention — naming your containers, watching the badges, and letting DevTools show you which rules are live. Once you've debugged a few, it'll feel like just another layout tool — much like CSS Grid did a few years ago — which is exactly the point.