Why CSS Media Queries Don’t Trigger at the Right Screen Width

You wrote a media query for phones. You resized your browser, crossed the width where the layout should change, and nothing happened. Or the change happened, but far too early, or far too late, leaving your design broken in a range of sizes you visit every day.

Media queries feel simple when you first learn them. One line of CSS checks the screen width and applies new rules. Yet several small details sit between that line and the browser: the viewport setting, the unit you used, the order of your rules, and even your browser zoom. Miss any one of them and the query fires at the wrong time, or never fires at all.

This guide goes through the causes in the order you should check them, so you can find your problem quickly instead of rewriting working CSS.

Quick Answer

Most media queries trigger at the wrong width because the page is missing the viewport meta tag, the breakpoint uses the wrong value or unit, a later rule overrides the query, or the browser is zoomed. Add <meta name="viewport" content="width=device-width, initial-scale=1">, check your breakpoint numbers, and make sure the media query comes after the base styles it should override.

What a Media Query Is Actually Measuring

A media query does not measure your physical screen in centimetres. It measures the width of the viewing area in CSS pixels. That sounds like a small distinction, but it explains a large share of confusion.

Modern phone screens have far more physical pixels than CSS pixels. A phone may have a display that is over a thousand physical pixels wide, yet it reports a layout width of around 390 CSS pixels. The browser scales things so text stays readable. Your media query responds to that reported layout width, not to the number printed on the phone box.

On a desktop, the CSS width also changes with zoom. At 150 percent zoom, a window that is 1200 physical pixels wide behaves like an 800 CSS pixel window. Your query is not broken when it fires during zoom. It is doing exactly what it was designed to do.

The MDN reference for using media queries describes this model in full, including how different media features are measured.

Cause 1: The Viewport Meta Tag Is Missing

This is the number one cause on real phones. Without the viewport tag, mobile browsers pretend the page is designed for a wide desktop, lay it out at a default width of around 980 CSS pixels, and then shrink the result to fit the screen. Your 600 pixel phone breakpoint never matches, because as far as the browser is concerned, the layout width is 980.

How to fix it

1. Open your HTML file and look inside the head section.
2. Add this line if it is not there: <meta name="viewport" content="width=device-width, initial-scale=1">
3. Save the file and fully reload the page on the phone, not just on your desktop.
4. Test the breakpoint again at phone width.

The tag tells the browser to set the layout width equal to the device width. Only then do your breakpoints describe the sizes you think they describe. If your site is generated by a theme or a builder, check the final page source in the browser, because the tag must appear in the delivered HTML, not just in a template you assume is used.

Cause 2: The Breakpoint Value or Unit Is Wrong

Simple typing mistakes

A query such as @media (max-width: 76px) instead of 768px fails silently. CSS does not warn you. The rule is valid, it simply matches almost nothing. Read each breakpoint digit by digit before you suspect anything deeper.

Mixing max-width and min-width

With max-width, the styles apply at that width and below. With min-width, they apply at that width and above. Beginners often write a desktop-first rule with min-width where they meant max-width, so the change happens in the opposite direction. Say the intention out loud, for example “these styles are for screens up to 768 pixels”, and check the code matches the sentence.

Em and rem breakpoints shift with font settings

If your breakpoint uses em units, its pixel value depends on the base font size used for media queries, which follows the browser or user font setting, not your page design. A 48em breakpoint is 768 pixels at the default 16 pixel base, but it moves if that base changes. If precision matters for your test, use pixels while you debug, so the number on the screen is the number in your code.

Cause 3: The Rules Are in the Wrong Order

CSS applies rules of equal strength in the order they appear in the file. A media query does not give its rules extra power. If your base style is written after your media query, the base style wins at every width, and it looks exactly as if the query never triggered.

1. Write your general, all-sizes styles first.
2. Place media queries after them in the same stylesheet.
3. For several breakpoints, order them logically: descending widths for max-width designs, ascending for min-width designs.
4. Repeat the check in every stylesheet, because a second file loaded later can override the first.

Strength matters too. A base rule with a more specific selector, such as an ID, will beat a simple class selector inside a media query. If order looks right but the rule still loses, compare the selectors, or use your browser tools to see which declaration is being struck through and why. Our beginner guide to how CSS specificity works walks through those comparisons with small examples.

Cause 4: Syntax Errors Stop the Query Silently

Media queries fail quietly when the syntax is off. Common problems include a missing closing brace before the query, a missing word such as and between conditions, and using a comma where you meant a range. One unclosed brace earlier in the file can also swallow everything after it, including perfectly written queries.

A quick syntax checklist

• The query starts with @media and the condition is inside round brackets.
• Multiple conditions are joined with and, for example (min-width: 600px) and (max-width: 900px).
• Every opening brace has a matching closing brace.
• Property names and values inside the block use normal CSS spelling.

Browsers offer a fast way to confirm a query matches. In developer tools you can resize the window and watch the styles panel. Rules inside a non-matching query appear dimmed. If your rules stay dimmed at widths where they should apply, the problem is the condition itself. If they appear active but the layout does not change, the problem is a losing rule or an override, not the query.

Cause 5: Your Testing Setup Is Lying to You

• Browser zoom: reset zoom to 100 percent with Ctrl+0 or Cmd+0 before testing breakpoints.
• Device toolbar settings: emulation modes apply their own scaling and sometimes a preset viewport, so note which mode you are in.
• Cached CSS: a hard refresh forces the browser to fetch the new stylesheet instead of reusing the old one.
• Testing the wrong window: media queries respond to the browser window or frame width, not the full monitor width, so a half-screen window is a valid smaller test.

The web.dev introduction to responsive web design basics is a helpful companion here, because it shows how viewport, zoom, and flexible layouts interact in real projects.

Common Mistakes to Avoid

• Designing for one exact phone: breakpoints should follow where your layout breaks, not a list of device models that will be outdated next year.
• Leaving gaps between ranges: styles set up to 767 pixels and from 769 pixels leave a one-pixel zone with no rules, which fractional widths can hit.
• Overlapping ranges with conflicting rules: two queries that both match and fight each other produce results that look random until you check the order.
• Testing only by dragging: dragging the window is useful, but final checks belong on the device toolbar widths and a real phone.
• Changing five things at once: fix one suspected cause, test, then move on, so you learn which change actually solved it.

Conclusion

When a media query fires at the wrong width, work through the causes in a sensible order. Confirm the viewport tag, read the breakpoint value and unit carefully, check that your queries come after the base rules they override, rule out small syntax errors, and make sure zoom or caching is not distorting your test. Most problems turn out to be one of these simple issues. Once you have fixed a few, you will spot the pattern in seconds the next time a breakpoint misbehaves.

Frequently Asked Questions

Why do my media queries work on desktop resize but not on my phone?

That pattern almost always points to the missing viewport meta tag. The desktop test uses the real window width, while the phone lays the page out at a wide default width and scales it down, so your phone breakpoints never match.

Should I use min-width or max-width for breakpoints?

Both work. Mobile-first designs usually use min-width, adding styles as screens grow. Desktop-first designs usually use max-width. Pick one approach per project and order your rules consistently so they do not fight.

Why does my breakpoint trigger at a different width than I set?

Check your zoom level and your unit. Zoom changes the CSS width of the window, and em breakpoints move with the base font size. Test at 100 percent zoom with a pixel breakpoint to see the exact behaviour.

Can JavaScript change when a media query applies?

JavaScript does not change the query itself, but scripts can add classes, inline styles, or resize elements, which can look like a query problem. If the CSS checks pass, inspect whether a script is modifying the same elements.

How do I know which breakpoint is active right now?

Open developer tools and resize slowly while watching the styles panel, or add a temporary background colour inside each query during testing. The colour that appears tells you exactly which range the browser thinks it is in.