What are Media Queries in CSS?

Resize a browser window on almost any site built in the last decade and the layout shifts at certain widths. Media queries are the CSS rule doing that work.

They gate a block of styles behind a condition: viewport width, screen resolution, whether the visitor has dark mode turned on. The CSS Working Group at the World Wide Web Consortium maintains the specification, and Chrome, Firefox, Safari and Edge each evaluate those conditions independently at render time.

Global browser support for the base CSS media query has reached 97.27% of worldwide usage, according to Can I Use data for August 2026, making it one of the most universally implemented features in CSS.

What Is a Media Query?

Conditions drive the whole thing. Width, resolution, orientation, color scheme preference: any of those can sit at the top of a style block and decide whether the browser applies what’s inside.

The rule lives inside CSS itself, so no plugins or extra libraries are needed. No JavaScript is required for the basic case either. The browser checks the condition and swaps styles the moment a match occurs.

What you need is the @media syntax from the CSS3 specification, a media type or a media feature (or both together), and a declaration block holding ordinary CSS rules. That’s the entire dependency list.

Ethan Marcotte coined the term responsive design in a 2010 A List Apart article, and media queries were the mechanism that made the idea usable in real browsers. Before that, sites often shipped separate mobile and desktop versions on different subdomains, doubling the maintenance work.

Unsupported browsers ignore a condition they don’t recognize and fall back to the base styles, which makes media queries a clean example of progressive enhancement.

Media Query Syntax

Every media query has the same shape. The @media keyword comes first, then an optional media type, then one or more conditions in parentheses, then a declaration block.

The media type names the output device: screen, print, all, or speech. The media feature is the condition being tested, written inside parentheses. Whatever sits in the declaration block gets applied when that condition matches.

A single rule can combine a type and a feature, such as screen and (min-width: 768px), or it can test a feature alone without naming a type at all.

Besides the @media rule inside a stylesheet, the same condition can sit on a link or style element in HTML through a media attribute. The picture element pairs that media attribute with a srcset attribute on each source tag, letting a browser swap entire image files per breakpoint instead of just swapping styles.

Media Types

Media types tell the browser which output device the styles target. Most of the historical list is formally deprecated now and defined to match nothing, including the once-common speech type.

Day-to-day CSS rarely needs anything beyond screen and print. Print still earns its own dedicated stylesheet for anyone who hits Control P.

The speech type, once intended for screen readers and speech synthesizers, was deprecated in Media Queries Level 4 alongside older legacy types such as tty, tv, projection, handheld, braille, embossed, and aural. All of these remain recognized syntax but are defined to match nothing, since browsers never implemented them consistently and assistive technology doesn’t rely on this media type in practice.

Logical Operators

Operators combine or exclude conditions inside a single rule.

• and requires both conditions to be true, as in screen and (min-width: 768px)
• or, written as a comma, matches if either condition is true, which helps when combining unrelated device types
• not reverses the result of the entire query, not just one feature
• only hides the query from older browsers that don’t understand media features, without affecting modern ones

Nesting works too. A component library might wrap a whole block of rules inside one width condition, then layer a second condition, such as orientation, inside it for finer control.

Specification Levels

The World Wide Web Consortium (W3C) and its CSS Working Group keep several levels of the media queries specification active at once, each at a different stage of maturity.

• Media Queries Level 3 reached full W3C Recommendation status, the most stable tier a specification can reach (W3C)
• Media Queries Level 4 still sits at Candidate Recommendation Draft as of February 2026, even though most of its features already ship in browsers (W3C)
• Media Queries Level 5 remains a Working Draft. After sitting unrevised since December 2021, the CSS Working Group published a new Working Draft on February 19, 2026 (W3C)

Spec status and real browser support rarely move at the same pace, which is why MDN Web Docs tracks which individual features from each level actually work in Google Chrome, Mozilla Firefox, and Safari.

Common Media Features and Their Values

Each feature accepts its own set of values. Width and height test the size of the viewport or, in the case of container queries, a containing element instead.

Resolution testing matters more than it used to, since screen resolution now varies wildly between a budget phone and a retina display sitting a few inches apart on a store shelf.

Orientation and aspect ratio get confused constantly. Orientation only reports portrait or landscape. Aspect ratio compares the exact width-to-height proportion of the viewport.

Then there’s input. The hover feature tests whether the primary input device can hover, separating a mouse from a touchscreen, while pointer reports how precise that device is, from coarse (a finger) to fine (a stylus or mouse). Used together they act as feature detection for input capability, instead of guessing input type from screen size alone.

prefers-color-scheme now ships in every major browser engine, which is why dark mode toggles built purely in CSS have become common on modern sites.

Media Query Breakpoints

A breakpoint is the pixel value in a media query where a layout changes shape. Most sites cluster theirs around small phones, large phones and small tablets, tablets and small laptops, then full desktop screens.

Bootstrap bases its breakpoints on a twelve-column grid system; per Bootstrap’s own documentation, each breakpoint size is chosen so that containers built from that grid comfortably hold widths that are multiples of twelve. Tailwind CSS takes a similar approach but names its tiers sm, md, lg, xl, and 2xl instead of using device labels.

A good breakpoint marks where the content itself starts to look cramped, not where a specific phone or tablet happens to end. Testing against real viewport widths, rather than a list of device names, keeps a layout working on hardware that doesn’t exist yet.

Mobile devices generated 62.73% of global website traffic in the second quarter of 2025 (StatCounter), which is one reason breakpoint decisions now start from the smallest screen rather than the largest. Some teams skip fixed breakpoints entirely and lean on a fluid layout that scales continuously instead of jumping at set points.

How to Write a Media Query

Skipping any part of the sequence below is the most common reason a rule silently does nothing.

1. Pick the media type. Use screen for on-screen layouts, print for paginated output, or leave it out entirely to match all devices.
2. Choose the feature and value. Decide what condition matters, such as min-width: 768px or prefers-color-scheme: dark.
3. Write the @media block. Wrap the condition in parentheses after the media type, separated by the word and if there is more than one condition.
4. Nest the CSS rules inside. Place ordinary selectors and declarations inside the curly braces, exactly as they would appear outside a media query.

So a rule like @media screen and (min-width: 768px) { .sidebar { display: block; } } keeps the sidebar hidden by default and reveals it only once the viewport reaches 768 pixels wide. That pattern shows up constantly in responsive navigation and grid layouts.

A media query written outside any selector, or placed inside a class definition instead of wrapping it, simply gets ignored by the parser without an error.

Mobile-First vs Desktop-First Media Queries

Mobile-first means min-width conditions that add complexity as the screen grows. Base styles target the smallest screen with no media query at all, and each added breakpoint layers on more layout rather than less. It matches how most visitors actually arrive at a page today.

Desktop-first flips that. Max-width conditions strip complexity away as the screen shrinks:

• Base styles target the widest layout first
• Each breakpoint removes columns and features for smaller screens
• Heavier desktop assets can keep loading on phones that never use them

Google’s search index has crawled the mobile version of pages as the primary version since 2018, which pushed mobile-first design from a nice-to-have into the default starting point for new CSS.

Desktop-first still shows up in older codebases and in dashboard-style tools where desktop remains the primary environment, such as internal admin panels or data-heavy back office software.

Media Queries vs Container Queries

A media query reacts to the browser viewport. A container query checks the size of its parent container instead, no matter how big the window happens to be.

A product card is the classic example. Under a media query, that card only knows the width of the whole screen, so a designer has to guess whether the card sits in a wide grid or a narrow sidebar. A container query lets the same card check its own box and adjust its own layout, which removes that guesswork entirely.

Firefox was the last of the three major engines to ship stable support, adding container queries in version 110 during early 2023. That’s one reason cross-browser compatibility concerns kept some teams on media queries alone until that year. GoogleChromeLabs maintains a container-query-polyfill for anyone still supporting older browser versions without waiting on native support.

The two aren’t rivals competing for the same job. A typical stylesheet today uses media queries for the page shell and container queries for the components living inside it.

Testing Media Queries Across Browsers and Devices

A media query that looks right in one browser can still break in another, so testing across real conditions catches what a single preview window hides.

Chrome DevTools handles most early testing. Its device toolbar simulates common screen widths and lets you drag the viewport edge to watch breakpoints fire in real time.

Emulation misses things, though. Actual touch behavior, for one, since a mouse cursor never truly matches a finger tap. Real network conditions on a physical carrier connection are another. Then there are quirks specific to a single rendering engine, older iPhone Safari builds being the usual culprit.

Testing on a real device still catches what emulation misses, especially around pixel density, where a retina display can render a breakpoint differently than a standard one sitting right next to it on a test bench.

Can I Use itself leans on BrowserStack for its own cross-device testing, a sign that even data-driven compatibility sites don’t trust emulation alone.

Resizing the browser window by hand remains one of the fastest sanity checks. Watch for a layout that jumps, overlaps, or clips text at the exact pixel where a breakpoint kicks in.

Browser Support for Media Queries

Support for media queries themselves stopped being a question years ago. Individual media features are a different story, and adoption varies a lot between them.

• Base CSS media query support sits at 97.27% of global browser usage (Can I Use, August 2026)
• prefers-color-scheme reaches 96.3% of global browser usage (Can I Use, August 2026)
• The dynamic-range media query appears in 3.263% of page loads, despite reaching Baseline Widely Available status in November 2024 (Chrome Platform Status)

That gap between support and actual usage is normal. A feature can be fully shipped in every major engine and still sit unused for years while developers catch up on it.

For a browser that lacks a given feature entirely, an adaptive design approach falls back to simpler, broadly supported styles instead of leaving the page broken.

MDN Web Docs pairs its browser compatibility tables with notes on known quirks and partial implementations, filling in detail that a bare percentage from Can I Use doesn’t show on its own.

Media Queries in JavaScript

CSS handles most responsive styling on its own, no script required. But JavaScript can read the same media conditions whenever something needs to react rather than just restyle.

Call window.matchMedia with a query string and it returns a MediaQueryList object. Its .matches property reports true or false at the moment the script checks it, and addEventListener lets the script respond again whenever the condition’s result flips.

The method works as a small API for testing media conditions from script, rather than a separate mechanism from the CSS version.

A common use case is detecting whether a site runs installed as a standalone app. window.matchMedia("(display-mode: standalone)").matches answers that question directly. The display-mode feature shows up in roughly 16.827% of page loads tracked by Chrome (Chrome Platform Status), a reasonable proxy for how often sites check for an installed or fullscreen context.

A plain @media rule swaps styles with no script cost at all. matchMedia only earns its keep when a layout change needs to trigger actual JavaScript logic, not just different styling.

Common Media Query Mistakes

Most media query bugs trace back to the same handful of errors, not exotic edge cases.

Specificity conflicts inside nested media queries are the hardest of these to spot, since the media condition itself has no effect on which selector wins. Running the competing selectors through a CSS specificity calculator settles the argument faster than guessing from stylesheet order.

Stacking breakpoints for every named device is the other frequent trap. A rule written for one exact phone width breaks the moment that phone gets replaced by a slightly different model next year.

When Media Queries Do Not Work

Media queries fail less often from browser bugs and more often from something missing elsewhere on the page.

• A missing viewport tag means mobile browsers ignore actual device width entirely
• An outdated browser may be too old for the specific feature being tested, dynamic-range or update for instance
• A specificity conflict lets a selector outside the media query win, so the rule inside never gets a chance to apply
• The layout issue belongs to a component’s own box rather than the page, which calls for a container query instead

That last case confuses teams most often. A card layout reused across a wide grid and a narrow sidebar cannot fix itself with a viewport-based rule, no matter how many breakpoints get added to it.

The scripting media feature exists specifically to detect when JavaScript is unavailable, yet Chrome’s own telemetry shows it appears in only 0.698% of page loads (Chrome Platform Status), meaning most sites still assume scripting works rather than testing for it.

And a typo in a feature name, max-widht instead of max-width, throws no error at all. The rule just never matches, and it sits there silently doing nothing.

FAQ on What Are Media Queries

How Is a Media Query Different From the Viewport Meta Tag?

They solve different problems. The meta tag sets actual device width so mobile browsers stop rendering at desktop scale, and a media query then applies conditional CSS on top of that corrected width.

Who Coined the Term Responsive Web Design?

Ethan Marcotte, in 2010. His definition rested on fluid grids, flexible images, and media queries working together. Of those, only the media query survives today as a distinct named technique in CSS3, credited directly to that original framework.

Do You Need a CSS Preprocessor Like Sass to Manage Breakpoints?

No preprocessor is required. Plain CSS handles breakpoints natively through the @media rule. Sass adds convenience once a stylesheet’s breakpoint count grows: reusable breakpoint variables, mixins that shorten repeated queries, nesting that keeps related rules together.

Should Breakpoints Use Px or Em Units?

Pixel breakpoints stay fixed no matter a visitor’s font-size setting, since px measures an absolute distance. Em breakpoints scale with that setting instead, shifting layout earlier for anyone who has increased text size. Weighing em vs rem settles most of that choice.

Does a Print Stylesheet Need Its Own Media Query?

Not strictly. Browsers apply print styles automatically when a page prints, even without an explicit rule. A dedicated print rule still matters when a layout needs to hide navigation, expand link URLs, or strip background colors for paper output.

What Should You Fix First When Media Queries Break Down?

Start with the viewport meta tag. Every width-based condition downstream depends on real device width instead of a shrunk desktop rendering scaled to fit.

1. Confirm the viewport meta tag is present and correct
2. Consolidate overlapping breakpoints into one scale
3. Cover prefers-color-scheme and prefers-reduced-motion last

That order matters because a wrong viewport value breaks every condition tested afterward, while overlapping breakpoints distort only specific widths, and missing accessibility features degrade the experience without blocking it.

Fixing structural width issues before refining accessibility features trades a short window of imperfect dark-mode support for a layout that renders correctly on every device first.

Once breakpoints and accessibility features hold steady, the next gap to close is usually responsive typography, since fixed font sizes are the last piece of a layout that still refuses to scale smoothly.