What Is a Media Query?
A media query is a CSS feature that applies styles only when conditions about the device or viewport are true, most commonly the screen's width. Written with the @media rule, it lets one stylesheet adapt a page to phones, tablets, and desktops, for example switching a three-column layout to a single column below a set width. Media queries are the mechanism behind responsive web design: instead of building separate mobile and desktop sites, you write conditional style blocks that reshape the same page to fit whatever screen is viewing it.
- What it is
- A CSS rule that applies styles only when device conditions match
- Written with
- The @media at-rule, e.g. @media (max-width: 768px) (MDN)
- Most common use
- Responsive layouts that adapt to viewport width
- Can test
- Width, height, orientation, resolution, and user preferences like dark mode
- Foundational to
- Responsive design, a Google mobile-friendly ranking factor (Google Search Central)
What a media query does #
A media query is a conditional block in CSS: the styles inside it apply only when the browser and device meet the conditions you specify. The most common condition is viewport width, so you can say, in effect, when the screen is narrower than 768 pixels, use these styles instead. Written with the @media at-rule, media queries let a single page reshape itself for phones, tablets, laptops, and large monitors without separate versions. This is the technical heart of responsive web design, the approach that replaced the old, unmaintainable habit of building a distinct mobile site. With media queries, the same HTML serves every device and CSS handles the adaptation. For small businesses, this means one site that looks right whether a customer visits from a phone on the go or a desktop at work, which is essential when most local searches happen on mobile. Responsive layouts built on media queries are standard in every site we produce under /services/web-design.
The anatomy of a media query #
A media query has a media type and one or more conditions. The type, usually screen, targets the kind of device, print is another, for styling how a page prints. The conditions, called media features, are wrapped in parentheses and test things like width. A typical query reads @media (max-width: 768px) { ... }, meaning apply the enclosed rules when the viewport is at most 768 pixels wide. You can combine conditions with and, comma-separated lists act as or, and modern syntax even allows range comparisons. Inside the braces you place normal CSS rules that override or add to your base styles when the condition holds. Because it is plain CSS, a media query can adjust anything, layout, font size, spacing, visibility. Understanding this structure lets you target exactly the situations you care about, which is why we treat breakpoints as deliberate design decisions rather than arbitrary numbers in the interfaces we build in /services/ui-ux-design.
/* Base styles: mobile first */
.grid { display: block; }
/* Two columns on tablets and up */
@media (min-width: 768px) {
.grid { display: grid; grid-template-columns: 1fr 1fr; }
}
/* Three columns on wide screens */
@media (min-width: 1200px) {
.grid { grid-template-columns: 1fr 1fr 1fr; }
}Mobile-first versus desktop-first #
There are two philosophies for writing media queries, and the choice shapes your whole stylesheet. Mobile-first means your base styles target small screens, and you use min-width queries to add complexity as the screen grows, layering in multiple columns and larger type for bigger viewports. Desktop-first does the opposite: base styles suit large screens, and max-width queries simplify things down for smaller ones. Mobile-first is the widely recommended approach because it forces you to prioritize essential content first and tends to produce leaner, faster styles for phones, where performance matters most and where most traffic now originates. It also aligns with how search engines evaluate sites, since Google predominantly uses the mobile version for indexing (Google Search Central). Building mobile-first keeps the core experience fast and focused, then enhances it for larger screens. This is the default methodology we follow when constructing responsive layouts, ensuring the phone experience, which most local customers use, is never an afterthought bolted on at the end.
Choosing breakpoints #
A breakpoint is the width at which your layout changes, defined by a media query's condition. A common mistake is picking breakpoints to match specific popular devices, chasing exact phone and tablet dimensions that constantly change. The better approach is to let your content decide: add a breakpoint wherever the layout starts to look cramped or awkward, regardless of which device that width corresponds to. That said, a small set of sensible ranges, roughly small phones, large phones, tablets, and desktops, gives a practical starting framework. Too many breakpoints make a stylesheet hard to maintain; too few leave awkward in-between sizes. The goal is a layout that looks intentional at every width, not just at a few tested ones. We choose breakpoints based on how a specific design behaves rather than a fixed device list, testing across a range of real widths, an approach that keeps sites looking polished on the endless variety of screens people actually use and that we bake into every /services/web-design build.
Beyond width: other conditions #
While width is the workhorse, media queries can test many other conditions. Orientation detects portrait versus landscape, useful for tablets. Resolution targets high-density retina screens so you can serve sharper assets. Aspect-ratio and height queries help with unusual layouts. Increasingly important are user-preference features: prefers-color-scheme lets you automatically apply dark styles when the user's system is set to dark mode, and prefers-reduced-motion lets you tone down animations for users who find motion uncomfortable, an accessibility win. There is also print media for styling how pages come out on paper. These conditions let a site respond not just to screen size but to context and user needs. Respecting prefers-reduced-motion, for instance, is part of building accessible interfaces, which connects directly to the standards work in /services/ada-compliance. Using the full range of media features thoughtfully turns a merely responsive site into one that genuinely adapts to how each person prefers to browse.
Media queries and Core Web Vitals #
Responsive design done with media queries affects performance and the metrics Google measures. A well-built responsive layout avoids serving desktop-sized images and heavy elements to phones, which keeps loads fast, though media queries alone do not shrink image files, that needs responsive image techniques alongside them. Poorly planned breakpoints can cause layout shifts as the page reflows, hurting Cumulative Layout Shift. Reserving space for elements and testing how layouts change across widths prevents this. Because search engines primarily crawl the mobile version of a site, a solid responsive foundation directly supports mobile-friendliness, a ranking consideration (Google Search Central). Media queries are one piece; they pair with optimized images, sensible font loading, and lean CSS to deliver a fast experience on every device. We verify real-world results across screen sizes using tools like /tools/website-grader, then tune both the responsive CSS and the assets it controls in /services/speed-optimization, so the site is not only flexible but genuinely fast on the phones most visitors carry.
Container queries: the newer sibling #
Media queries respond to the viewport, the whole browser window, but sometimes you want a component to adapt to the space it sits in, not the screen. That is what container queries, a newer CSS feature now supported in modern browsers, provide. A card that appears in a wide main column and also in a narrow sidebar can, with container queries, restyle itself based on its own container's width rather than the page width. This makes truly reusable, context-aware components possible, something media queries cannot do alone. Media queries remain the right tool for page-level layout and global responsive behavior, while container queries handle component-level adaptation. The two complement each other, and modern responsive design increasingly uses both. We adopt container queries where they make components more robust and reusable, especially in the systematic, component-driven interfaces we build in /services/web-app-development, giving each element the ability to look right no matter where in the layout it is placed.
Testing and common mistakes #
Responsive layouts must be tested across real widths, not just the few a designer happened to check. A frequent mistake is designing only for a couple of exact device sizes and leaving awkward gaps in between, where a layout looks broken at, say, 900 pixels. Another is forgetting the viewport meta tag in the HTML head, without it, mobile browsers assume a desktop width and your media queries never trigger correctly, a classic reason a supposedly responsive site still looks tiny on phones. Overlapping or contradictory breakpoints, and using too many, also cause bugs and maintenance pain. Hiding content on mobile rather than adapting it can harm both usability and SEO if important information disappears. We test across a continuous range of widths and on real devices, confirm the viewport meta tag is present, and make sure no content vanishes, so the responsive behavior is reliable everywhere. This thoroughness is standard in the sites we launch under /services/web-design, where a broken mobile view directly costs a small business customers.
FAQ
What is a media query used for?
It applies CSS styles only when device conditions match, most often viewport width. This lets one page adapt to phones, tablets, and desktops, the foundation of responsive design. For example, a media query can switch a three-column desktop layout to a single column on narrow phone screens, all from one stylesheet.
What is the difference between min-width and max-width?
A min-width query applies its styles when the viewport is at least that wide, used in mobile-first design to add complexity as screens grow. A max-width query applies when the viewport is at most that wide, used in desktop-first design to simplify for smaller screens. Mobile-first with min-width is generally recommended.
How do I choose breakpoints?
Let your content guide you: add a breakpoint wherever the layout starts looking cramped, rather than chasing exact device sizes that keep changing. A small set of ranges for phones, tablets, and desktops is a practical start. Test across many widths so the design looks intentional at every size, not just a few.
Why isn't my media query working on mobile?
The most common cause is a missing viewport meta tag in your HTML head. Without it, mobile browsers assume a desktop width and your width-based queries never trigger correctly. Add <meta name="viewport" content="width=device-width, initial-scale=1">. Also check for typos, overlapping breakpoints, or conflicting rules overriding your styles.
What is the difference between media queries and container queries?
Media queries respond to the whole viewport, the browser window, so they drive page-level responsive layout. Container queries, a newer feature, let a component adapt to the size of its own container instead, so the same card can restyle itself in a wide column or a narrow sidebar. Both are used together in modern design.
Can media queries detect dark mode?
Yes. The prefers-color-scheme feature lets a media query apply styles when the user's system is set to dark or light mode, so your site can automatically match. Similarly, prefers-reduced-motion detects users who want less animation, letting you build a more accessible, preference-aware experience beyond just screen size.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?