The New CSS Media Query Range Syntax

CSS media queries have long been the foundation of responsive design, but the traditional min-width and max-width syntax can become awkward as layouts grow more complex. The newer media query range syntax lets you express viewport conditions with familiar comparison operators like >=, <=, >, and <, making breakpoints read more like plain conditions.

Instead of writing separate feature names for lower and upper bounds, you can define ranges directly: @media (width >= 768px) or @media (768px <= width < 1200px). This improves clarity, reduces repetition, and makes it easier to see exactly when a rule applies, especially in component-driven stylesheets or design systems with many breakpoint layers.

#	Preview	Product	Price
1		CSS Pocket Reference: Visual Presentation for the Web	$19.93	Buy on Amazon
2		CSS Pocket Reference: Quick Syntax, Selectors, Properties, Flexbox, Grid, and Responsive Design	$11.90	Buy on Amazon
3		CSS Pocket Reference: Visual Presentation for the Web	$6.16	Buy on Amazon
4		Modern Web Design Using HTML and CSS: A Comprehensive Reference for Creating Responsive Websites,...	$34.00	Buy on Amazon
5		HTML CSS Cheat Sheet, Cover all Basic Html Css Syntaxes, Quick Reference Guide by Examples, ISBN:...	$19.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Used thoughtfully, range syntax can make responsive CSS easier to maintain while still fitting alongside existing media queries. Understanding its syntax, support profile, and migration path helps you adopt it safely without disrupting older stylesheets or browsers that may still depend on the classic approach.

What the New Media Query Range Syntax Looks Like

The modern CSS media query range syntax lets you write viewport and feature comparisons in a way that looks closer to ordinary mathematical expressions. Instead of wrapping a feature name in min- or max-, you compare the media feature directly with a value using operators such as <, <=, >, and >=. This makes the condition easier to scan, especially when a query expresses a range between two breakpoints.

#1 Best Overall

Sale

CSS Pocket Reference: Visual Presentation for the Web

$19.93

Buy on Amazon

A traditional mobile-first query might look like this:

@media (min-width: 768px) {
.layout {
display: grid;
}
}

With range syntax, the same condition can be written as:

@media (width >= 768px) {
.layout {
display: grid;
}
}

The media feature, width, is compared directly against 768px. Read aloud, this says: apply these styles when the viewport width is greater than or equal to 768 pixels. The equivalent older syntax says the same thing, but indirectly, through the special min-width prefix.

Single-sided range queries

Single-sided comparisons are the simplest use case. They replace common min-width and max-width queries with explicit operators:

• @media (width >= 1024px) replaces @media (min-width: 1024px).
• @media (width <= 767px) replaces @media (max-width: 767px).
• @media (width > 480px) applies only above 480px, excluding exactly 480px.
• @media (width < 1200px) applies below 1200px, excluding exactly 1200px.

The distinction between inclusive and exclusive comparisons is useful. >= and <= include the boundary value, while > and < exclude it. In responsive design, inclusive operators are often the clearest choice when matching existing min-width or max-width breakpoints.

Two-sided range queries

The range syntax becomes especially readable when defining a band between two sizes. Older CSS usually combines two conditions with and:

@media (min-width: 768px) and (max-width: 1199px) {
.sidebar {
display: none;
}
}

The modern form can express the same range in one chained comparison:

@media (768px <= width <= 1199px) {
.sidebar {
display: none;
}
}

This reads as: apply these styles when the viewport width is between 768px and 1199px, inclusive. You can also mix inclusive and exclusive boundaries to avoid overlap between adjacent breakpoint ranges:

@media (768px <= width < 1200px) {
.card-grid {
grid-template-columns: repeat(2, 1fr);
}
}

That query includes 768px and excludes 1200px, which pairs neatly with a later rule such as @media (width >= 1200px). This avoids the old habit of writing values like 1199.98px to prevent two media queries from matching at the same boundary.

Range syntax is not limited to width

Although viewport width is the most common example, range comparisons work with other range-capable media features too. For example, you can query viewport height, aspect ratio, resolution, and color capability when the feature supports range comparisons:

• @media (height < 700px) for shorter viewports.
• @media (aspect-ratio >= 16/9) for wide screens.
• @media (resolution >= 2dppx) for high-density displays.

The result is a more consistent syntax across responsive conditions. Instead of remembering whether a feature needs min-, max-, or a combined query, you can often describe the condition directly with a comparison operator.

Rank #2

CSS Pocket Reference: Quick Syntax, Selectors, Properties, Flexbox, Grid, and Responsive Design

$11.90

Buy on Amazon

How Range Syntax Compares to min-width and max-width

Traditional media queries express ranges by prefixing a media feature with min- or max-. For example, @media (min-width: 768px) applies when the viewport is at least 768 pixels wide, while @media (max-width: 767px) applies up to 767 pixels. The modern range syntax keeps the same behavior but writes the comparison more like ordinary math: @media (width >= 768px) or @media (width < 768px).

The biggest improvement is readability, especially when a query has both a lower and upper bound. A classic bounded query often looks like this: @media (min-width: 768px) and (max-width: 1023px). With range syntax, the same intent can be written as @media (768px <= width < 1024px). That form makes it immediately clear that the styles apply between two values. It also reduces the mental translation required to understand whether the limits are inclusive or exclusive.

Common equivalents

Range syntax is particularly useful for avoiding awkward breakpoint gaps and overlaps. In older stylesheets, teams often subtract a pixel from the next breakpoint, such as using max-width: 767px before min-width: 768px. Some codebases use fractional values like 1023.98px to avoid collisions on high-density screens or browser zoom states. With comparison operators, you can write (width < 768px) for one range and (width >= 768px) for the next, making the boundary explicit without relying on magic-looking decimals.

The newer syntax also scales better when breakpoints are named in design tokens or custom tooling. A design system might define small, medium, and large viewport bands, then generate queries such as (48rem <= width < 64rem). This reads as a continuous interval instead of two separate conditions joined with and. For teams reviewing CSS, that small improvement can make responsive rules easier to scan and less prone to off-by-one mistakes.

There is still nothing wrong with min-width and max-width. They remain valid, widely understood, and useful in projects that must support older browsers. The range syntax is best seen as a clearer way to express the same , not a different responsive design model. Use it when browser targets allow it, when writing new breakpoint rules, or when refactoring complex queries where explicit operators make the intended viewport range easier to understand.

Writing Common Responsive Breakpoints with Range Operators

Range operators make breakpoint rules read more like the design intent behind them: “apply this from 48rem and up,” “apply this below 40rem,” or “apply this only between tablet and small desktop sizes.” Instead of translating those ideas into min-width and max-width, you can write the comparison directly against the media feature.

For mobile-first responsive design, the most common pattern is a lower-bound query. This applies styles once the viewport reaches a certain size and keeps them active for larger screens. With range syntax, that looks like this:

@media (width >= 48rem) {
.layout {
display: grid;
grid-template-columns: 2fr 1fr;
}
}

This is equivalent to a traditional @media (min-width: 48rem) query, but the relationship is clearer at a glance: the width must be greater than or equal to 48rem. This style works especially well for layout changes such as switching from a single-column mobile layout to a two-column tablet layout.

For desktop-first stylesheets, or for small-screen overrides, an upper-bound query is just as direct:

@media (width < 40rem) {
.nav {
display: none;
}

.menu-button {
display: inline-flex;
}
}

This targets viewports narrower than 40rem. If you want the boundary value included, use <= instead. Being explicit about inclusive and exclusive limits helps avoid accidental overlap between adjacent breakpoints.

Rank #3

CSS Pocket Reference: Visual Presentation for the Web

$6.16

Buy on Amazon

Targeting a specific range

One of the biggest readability improvements appears when defining a middle range, such as tablet-only styles. Instead of combining min-width and max-width, you can chain the comparison:

@media (48rem <= width < 64rem) {
.card-grid {
grid-template-columns: repeat(2, 1fr);
}
}

This reads as “when the width is at least 48rem and less than 64rem.” It also avoids the common off-by-one-style patterns often seen in older CSS, such as max-width: 63.999rem, which were used to prevent two breakpoint rules from applying at the same time.

In practice, choose breakpoints based on when the design needs adjustment rather than on specific device names. A product card might need two columns at 42rem, while the main page shell might not need a sidebar until 64rem. Range operators make these component-level decisions easier to express because each condition can describe the exact span where that component looks best.

Using rem values for breakpoints is often preferable because they scale with the user’s root font size. Pixel-based breakpoints still work, but rem can better respect accessibility settings. Whichever unit you use, keep boundaries consistent: prefer adjacent ranges like (width < 48rem) and (width >= 48rem) so there is no gap or unintended overlap.

Combining Range Conditions with Other Media Features

Range syntax is not limited to viewport width. It can be combined with the rest of the media query system, including input capabilities, user preferences, viewport height, aspect ratio, resolution, and color features. This makes it useful for responsive design that adapts not only to screen size, but also to the way a person interacts with the page and how their device renders content.

The most common pattern is to pair a width range with another condition using and. For example, a layout may switch to a wider navigation only on medium-to-large screens that also support hover interaction. In traditional syntax, this often becomes visually noisy as several min- and max- clauses pile up. With range syntax, the size boundary stays compact and reads more like the design rule it represents.

@media (48rem <= width < 80rem) and (hover: hover) {
.site-nav {
display: flex;
}

.site-nav__item:hover .site-nav__submenu {
display: block;
}
}

This approach is especially helpful when separating touch-first behavior from pointer-friendly behavior. A tablet-sized viewport does not guarantee a mouse or trackpad, and a small viewport does not always mean touch input. Combining width with hover, pointer, or any-pointer lets the stylesheet describe real interaction constraints rather than relying on width as a proxy for device type.

Common combinations

• Width plus hover: Use larger menus, tooltips, or hover previews only when the viewport has enough room and hover is available.
• Width plus pointer accuracy: Increase control density when (pointer: fine) is present, and keep larger tap targets for coarse pointers.
• Width plus user preferences: Combine ranges with (prefers-reduced-motion: reduce) or (prefers-color-scheme: dark) for layout and presentation changes that respect user settings.
• Width plus height: Target short landscape screens separately from taller desktop windows, which is useful for sticky headers, modals, and full-screen panels.
• Width plus resolution: Serve denser decorative assets or adjust fine visual details only inside suitable viewport ranges.

@media (width >= 64rem) and (height < 40rem) {
.hero {
min-height: auto;
padding-block: 2rem;
}
}

@media (width > 75rem) and (prefers-color-scheme: dark) {
.dashboard {
border-color: color-mix(in srgb, white 18%, transparent);
}
}

Range conditions can also be grouped with comma-separated media queries, where each comma acts like an alternative match. This is useful when two different contexts should receive the same styles. For instance, you might apply a compact toolbar on narrow screens, and also on wider screens with limited height. Keep these grouped queries short; if the condition becomes hard to scan, split the rule into separate blocks with shared custom properties or utility classes.

@media (width < 40rem), (height < 32rem) and (pointer: coarse) {
.toolbar {
gap: 0.5rem;
}

.toolbar__label {
display: none;
}
}

When combining features, prefer conditions that map directly to the design decision. Use width ranges for available horizontal space, height ranges for vertical constraints, and interaction features for input behavior. This keeps breakpoints maintainable as new devices appear, because the query describes the capability the component needs rather than a specific phone, tablet, or laptop category.

Rank #4

Modern Web Design Using HTML and CSS: A Comprehensive Reference for Creating Responsive Websites, Interactive Interfaces, and Accessible Digital ... Today, Professional Tomorrow in Tech)

$34.00

Buy on Amazon

Browser Support and Progressive Enhancement

CSS media query range syntax is supported in current versions of all major browser engines, including Chromium-based browsers, Firefox, and Safari. That makes queries such as @media (width >= 768px) and @media (400px <= width < 900px) safe for many modern production projects, especially when your audience is using evergreen browsers. The feature is part of Media Queries Level 4, and its main value is syntactic clarity rather than a new layout capability, so it maps closely to the older min-width and max-width patterns.

The main support consideration is older browsers. Legacy versions of Safari, Chrome, Edge, Firefox, and older embedded webviews may not understand range comparison operators such as <, <=, >, and >=. When a browser cannot parse a media query, it drops that entire query. For example, an unsupported browser will ignore @media (width >= 64rem) rather than trying to interpret it as @media (min-width: 64rem). This behavior is predictable, but it means you should not rely on range syntax alone if unsupported browsers still matter for your product.

Progressive enhancement patterns

A practical approach is to keep the baseline design outside media queries, then layer enhancements inside range queries. This works well when the default layout is usable on narrow screens and larger-screen refinements are optional. For wider compatibility, you can also pair a traditional query with the modern equivalent during a transition period. Place the older syntax first, then the range syntax after it, so modern browsers receive the clearer rule last if both blocks contain overlapping declarations.

• Modern-only enhancement: use range syntax when the affected styles are refinements and the unsupported fallback remains acceptable.
• Compatibility-first breakpoint: use min-width and max-width when the breakpoint is required for critical layout behavior in older browsers.
• Dual syntax migration: write both forms temporarily when you need modern readability without dropping support for older clients.

For example, a stylesheet might define a single-column card grid by default, use @media (min-width: 48rem) for broad compatibility, and later add or replace it with @media (width >= 48rem). The declarations inside those two queries can be identical during migration. Once analytics show that unsupported browsers are no longer relevant, the older block can be removed. This keeps the change low-risk because the visual behavior does not need to change at the same time as the syntax.

Checking support before switching

Before converting a large stylesheet, check your project’s browser support policy rather than relying on general compatibility claims. Public support tables are useful, but your own traffic data is more valuable. Pay special attention to in-app browsers, kiosk devices, old tablets, enterprise-managed machines, and embedded webviews, because they may lag behind desktop browser releases. If your CSS is distributed as part of a design system or component library, document whether consumers are expected to support range syntax directly or compile it away during their build process.

Build tooling can help, but do not assume every PostCSS or minification pipeline automatically transforms range media queries into min- and max- syntax. If you need automated fallback output, verify the exact plugin behavior and inspect the generated CSS. The safest migration path is incremental: convert a small group of non-critical breakpoints, test in your supported browsers, confirm that invalid range queries are ignored cleanly where unsupported, and then continue with broader refactoring.

Tips for Migrating Existing Media Queries

Migrating an existing stylesheet to the new media query range syntax is best handled gradually. There is usually no need to rewrite every min-width and max-width query at once, especially in a mature codebase with many layout rules. Start with the media queries you touch most often: core layout breakpoints, component-level queries, and any conditions that currently feel hard to read because they combine both lower and upper bounds.

A good first pass is to convert obvious one-to-one cases. For example, @media (min-width: 768px) can become @media (width >= 768px), while @media (max-width: 767px) can become @media (width <= 767px). For bounded ranges, the improvement is even clearer: @media (min-width: 768px) and (max-width: 1199px) can be rewritten as @media (768px <= width <= 1199px). This makes the intended interval visible at a glance and reduces the mental mapping between property names and comparison direction.

Use consistent boundary rules

Before migrating, decide how your team wants to express breakpoint edges. Many existing stylesheets use pairs such as max-width: 767px followed by min-width: 768px to avoid overlap. With range syntax, you can keep that model by writing (width < 768px) for smaller screens and (width >= 768px) for the next range. This avoids awkward off-by-one values and is easier to maintain when breakpoints change.

• Mobile first: prefer lower-bound queries such as @media (width >= 48rem) for enhancements as space increases.
• Desktop first: use upper-bound queries such as @media (width < 64rem) when reducing complexity for smaller viewports.
• Exclusive ranges: use < and > when adjacent breakpoints should not overlap.
• Inclusive ranges: use <= and >= when matching exact breakpoint values is intentional.

During migration, search for repeated breakpoint values and replace hard-coded conditions in clusters rather than one at a time. If your project uses custom properties, Sass variables, design tokens, or a breakpoint map, update the shared breakpoint definitions and helper mixins first. For example, a Sass mixin that currently outputs (min-width: $tablet) could be adjusted to output (width >= $tablet). That keeps component styles consistent and prevents the codebase from drifting between old and new patterns.

Best Value

HTML CSS Cheat Sheet, Cover all Basic Html Css Syntaxes, Quick Reference Guide by Examples, ISBN: 9798877126046: Html Css Programming Syntax Book, Syntax Table & Chart, Quick Study Workbook

$19.99

Buy on Amazon

Be careful with legacy fallbacks if your audience includes older browsers that do not support range context syntax. One practical approach is to leave critical layout queries in the traditional form until your browser support target allows the newer syntax. Another option is to place older queries first and then add equivalent range-syntax queries later for styles you are actively modernizing. Automated tools, visual regression tests, and viewport-based QA are especially useful here, because a tiny change from <= to < can affect the exact breakpoint where a layout switches.

Finally, document the convention in your project’s CSS guidelines. State whether the team prefers px, rem, or tokenized breakpoints, whether breakpoint starts are inclusive, and whether range syntax is required for new code. Once the rule is clear, migration becomes a routine cleanup task rather than a risky rewrite.

Frequently Asked Questions

Can I replace all my min-width and max-width media queries with the new range syntax?

Yes, if your supported browsers understand Media Queries Level 4 range syntax. For example, @media (min-width: 768px) can become @media (width >= 768px), and @media (max-width: 1023px) can become @media (width <= 1023px). If you still support older browsers, keep the traditional syntax or provide it as a fallback.

Is there a difference between using width <= 768px and max-width: 768px?

For most responsive layouts, they behave the same. The range syntax is mainly clearer when you are expressing comparisons, especially combined ranges like (768px <= width < 1200px). Be careful with inclusive and exclusive operators because <= includes the exact value, while < does not.

How do I write a media query for screens between two breakpoints?

You can write a chained range such as @media (768px <= width < 1200px). This targets viewports from 768px up to, but not including, 1200px. The equivalent older syntax is @media (min-width: 768px) and (max-width: 1199.98px), depending on how you handle breakpoint boundaries.

Does the new range syntax work with features other than width?

Yes, it works with range-based media features such as height, aspect-ratio, resolution, and some color-related features. For example, you can use @media (height > 700px) or @media (aspect-ratio > 16/9). You can also combine these with non-range features like (hover: hover) or (prefers-reduced-motion: reduce).

What is the safest way to migrate an existing stylesheet?

Start with media queries that are easy to verify, such as simple min-width breakpoint rules. Replace them with range syntax only if your browser support target allows it, and test layout changes at the exact breakpoint values. For shared codebases, consider migrating gradually so the new syntax does not make debugging harder for teams still used to the older format.

Bottom Line

The new CSS media query range syntax makes responsive rules easier to read by letting you write conditions closer to the way you think about them, such as (width >= 768px) or (480px <= width < 1024px). It is especially useful when defining clear breakpoint ranges, reducing the mental overhead of matching min-width and max-width pairs.

For new projects, start using range syntax where your browser support targets allow it, and keep legacy syntax only when you need broader compatibility. For existing stylesheets, migrate gradually during refactors, test breakpoints carefully, and favor consistency so your responsive CSS stays readable and maintainable.

Quick Recap

SaleBestseller No. 1

CSS Pocket Reference: Visual Presentation for the Web

$19.93

Bestseller No. 2

CSS Pocket Reference: Quick Syntax, Selectors, Properties, Flexbox, Grid, and Responsive Design

$11.90

Bestseller No. 3

CSS Pocket Reference: Visual Presentation for the Web

$6.16

Bestseller No. 4

Modern Web Design Using HTML and CSS: A Comprehensive Reference for Creating Responsive Websites, Interactive Interfaces, and Accessible Digital ... Today, Professional Tomorrow in Tech)

$34.00

Bestseller No. 5

HTML CSS Cheat Sheet, Cover all Basic Html Css Syntaxes, Quick Reference Guide by Examples, ISBN: 9798877126046: Html Css Programming Syntax Book, Syntax Table & Chart, Quick Study Workbook

$19.99

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.