A CSS media query is the most fundamental responsive tool there is: it lets your design apply different styles based on screen size, orientation, or user preferences. A table that overflows on a phone, a button that looks huge on desktop, a section that triggers a horizontal scrollbar — almost all of these come from missing or poorly planned breakpoints. In this guide I'll walk through building a mobile-first breakpoint strategy from scratch, the most common mistakes, and the modern alternatives, with practical examples.
How a media query works
A media query combines a media type (usually screen) with one or more conditions. If the condition is true, the rules inside apply; otherwise they are skipped. The most common conditions are min-width and max-width.
/* Applies on screens 600px and wider */
@media (min-width: 600px) {
.card {
display: grid;
grid-template-columns: 1fr 1fr;
}
}The key detail: min-width: 600px means "if the width is 600px or more." max-width: 600px means "if the width is 600px or less." Confusing these two is the number-one cause of responsive bugs.
Why mobile-first wins
There are two strategies: adding rules from small to large screens (mobile-first, with min-width) or overriding rules from large to small (desktop-first, with max-width). There are concrete reasons to prefer mobile-first:
- The default style is the simplest: you write the base styles as a single column and only add complexity as the screen grows.
- Fewer overrides: if you start with
max-width, you constantly have to undo large-screen styles, which makes your CSS fragile. - Performance: a mobile device doesn't have to evaluate desktop rules that don't concern it.
In practice, write your base style with no media query at all, then add min-width blocks for larger screens:
/* Mobile: default, single column */
.grid { display: grid; gap: 16px; }
/* Tablet and up */
@media (min-width: 768px) {
.grid { grid-template-columns: repeat(2, 1fr); }
}
/* Desktop */
@media (min-width: 1024px) {
.grid { grid-template-columns: repeat(3, 1fr); }
}Where should breakpoints go?
A common misconception is to set breakpoints by the pixel widths of popular devices (iPhone, iPad, and so on). Device models keep changing; today's "standard" is obsolete tomorrow. The right approach is to place a breakpoint where the content breaks. Slowly widen your design; when lines get too long to read comfortably or a card squeezes in an ugly way, put a breakpoint there.
A starting point still helps, though. In most projects these three or four ranges do the job:
- ~480–600px: large phone / small tablet transition
- ~768px: tablet, moving from a stacked layout to multiple columns
- ~1024px: small desktop / landscape tablet
- ~1280px+: wide desktop, capping the content width
Don't treat these values as sacred; shift them to match the real content of your project.
px, em, rem: picking the right unit
Using em instead of px in media query conditions has one advantage: when a user increases the browser's font size, the breakpoints scale too, which improves accessibility. An em inside a media query is calculated against the root font size (usually 16px), so 37.5em ≈ 600px.
@media (min-width: 48em) { /* ~768px */
.sidebar { position: sticky; top: 0; }
}The general rule: em is a consistent choice for layout breakpoints, but px is perfectly valid too. Pick one standard on your team and stick to it.
Media queries beyond width
Media queries aren't only about width. A few powerful uses:
- Orientation:
@media (orientation: landscape)for a layout specific to landscape mode. - Dark mode:
@media (prefers-color-scheme: dark)to match the system theme. - Reduced motion:
@media (prefers-reduced-motion: reduce)to turn off animations; this is an accessibility requirement. - Pointer type:
@media (hover: hover)to give hover effects only on devices with a mouse.
@media (prefers-reduced-motion: reduce) {
* { animation-duration: 0.01ms !important; transition: none !important; }
}The modern alternative: container queries
Media queries always look at the viewport. But often what you want is for a component to adapt to the width of its own container. That's where @container queries come in, and they are now supported in all current browsers.
.list { container-type: inline-size; }
@container (min-width: 400px) {
.card { display: flex; gap: 12px; }
}This lets the same card component stack vertically in a narrow sidebar and sit side by side in a wide main area — without touching any global breakpoints. Container queries don't replace media queries, they complement them: media queries for page layout, container queries for reusable components is a good division of labor.
The non-negotiable: the viewport meta tag
For all your media queries to work correctly on mobile, the page must include this line in its <head>. Without it, a phone renders the page at desktop width and shrinks it down, and your breakpoints won't fire:
<meta name="viewport" content="width=device-width, initial-scale=1">Frequently Asked Questions
Should I use min-width or max-width?
If you work mobile-first, lean on min-width: the base style is mobile and you add on as it grows. Stick to one strategy; mixing both haphazardly leads to conflicting rules and CSS that's hard to debug.
How many breakpoints should I use?
There's no fixed number. Most sites work fine with three or four. Place them where the content breaks, not by device model. Unnecessary breakpoints just make maintenance harder.
Will container queries replace media queries?
No, the two are used together. Media queries make sense for overall page layout and global thresholds, while container queries fit components that adapt to their context.
Need a responsive interface? I build sites that look flawless on every screen with a mobile-first, clean, and maintainable CSS architecture. To talk about your project, get in touch with me.