Stop Using Media Queries for Everything: Learn CSS Container Queries

Every frontend developer reaches for media queries as the default tool for responsive design. For years, that's made sense media queries check the size of the browser viewport and adjust styles accordingly.

But once you start building smaller, reusable pieces of UI sidebar widgets, product cards, dashboard tiles media queries alone start to fall short. This is where CSS container queries come in, and if you're building components for real projects, they're worth adding to your toolkit today.

Quick Introduction

If you're still getting comfortable with component-based frontend development in general, my post on how to learn React is a good companion read alongside this one.

In this blog, I'll cover:

• Media Queries Syntax
• CSS Media Types
• Enter Container Queries
• Why This Matters for Component-Driven Design
• Browser Support: When to Use Them
• Conclusion

Media Queries Syntax

Media queries let you apply CSS styles based on features of a device or the environment a webpage is displayed in. They're the foundation of responsive web design, and you add them to a stylesheet using the @media rule.

A media query consists of an optional media type and one or more media features, each of which resolves to either true or false:

@media [not] media-type and (media-feature: value) and (media-feature: value) {
  /* CSS rules to apply */
}

The media type is optional — but if you use not, you must specify a media type explicitly.

The overall query evaluates to true if the specified media type matches the current device and all listed media features are also true. When that happens, the corresponding style rules are applied.

CSS Media Types

The optional media type specifies which kind of media the styles are meant for. If it's omitted, it defaults to all.

Value	Description
all	Used for all media type devices
print	Used for print preview mode
screen	Used for computer screens, tablets, and smartphones

This works well at the page level. But a card or widget component doesn't actually care how wide the browser window is — it cares how much space it has been given inside its parent. That's the gap container queries were built to close.

Enter Container Queries

Container queries flip the logic. Instead of asking "how wide is the browser window?", they ask "how wide is the element's parent container?" This means a single component can adapt intelligently no matter where it's placed on the page.

Here's the basic syntax:

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

@container card (min-width: 400px) {
  .card {
    display: flex;
    gap: 1rem;
  }
}

Two things are happening here:

1. container-type: inline-size tells the browser to treat this element as a query container, tracking its inline (usually horizontal) size.
2. @container is the at-rule that lets you write conditional styles based on that container's size, not the viewport.

Now the .card component adapts based on the space it's actually given — whether that's a full-width hero section or a 300px sidebar slot.

Why This Matters for Component-Driven Design

Modern frontend development leans heavily on reusable components — design systems, React component libraries, CMS-driven page builders. These components get dropped into all kinds of layouts, often ones the original developer never anticipated.

Container queries make components genuinely self-sufficient. They don't need to know about the page; they only need to know about their own boundaries.

That's a meaningful shift in mindset: responsive design stops being purely a page-level concern and becomes something you build directly into individual components.

Browser Support and When to Use Them

Container queries now have solid support across all major modern browsers — Chrome, Firefox, Safari, and Edge. For most production use cases today, they're safe to adopt, especially with a graceful fallback in place for older browsers if you need to support legacy environments.

That said, container queries aren't a full replacement for media queries — they solve a different problem. Use media queries for overall page-level layout decisions (like switching from a single-column to a multi-column layout based on viewport width), and use container queries when a specific component needs to adapt based on its own available space.

Conclusion

Media queries aren't going away, but relying on them for every responsive decision creates unnecessary rigidity. Container queries give developers a more precise, component-first tool — one that matches how modern UIs are actually built.

If you're designing reusable components, it's worth adding container queries to your toolkit today. Want to go deeper? Check out more frontend breakdowns like this on the CodeWithAmrendra blog. And if you'd like to talk shop, learn more about my work on the about page, or hire me for your next project. You can also get in touch here.

Happy coding!