I’ve debugged media query issues across more WordPress sites than I care to count. Client sites, my own projects, plugin sandboxes. And almost every time, it comes down to one of six things.
The frustrating part isn’t that media queries are hard. They aren’t. The frustrating part is that WordPress adds layers — theme stylesheets, plugin CSS, the block editor injecting its own styles — that silently break responsive rules you wrote perfectly.
This post covers every real cause I’ve run into and exactly how to fix each one.
Why Media Queries Break Specifically in WordPress
Before jumping to fixes, it helps to understand why this happens in WordPress and not in a plain HTML file.
WordPress loads CSS in a specific order through its enqueue system. Your media query might be correct, but if another stylesheet loads after yours with higher specificity, your responsive rules lose. The viewport meta tag might be missing if you’re using a lightweight or poorly built theme. And if you’re adding custom CSS through the Customizer instead of a proper file, caching can serve stale styles that ignore your changes entirely.
None of this is obvious. That’s why the same media query that works on your test page fails on the live site.
6 Ways to Fix Media Query Not Working in WordPress
Fix 1: Check Your Syntax First — This Catches 60% of Issues
Start here. Every time.
The most common reason a media query doesn’t work is a syntax error — a missing bracket, an unclosed parenthesis, a misplaced semicolon. The browser silently skips the broken rule and you spend an hour looking for something else.
Correct syntax:
@media screen and (max-width: 768px) {
.your-element {
font-size: 16px;
}
}Common mistakes:
/* Missing closing bracket on the rule */
@media screen and (max-width: 768px) {
.your-element {
font-size: 16px;
}
/* Wrong: no 'and' keyword */
@media (max-width: 768px) screen {
...
}Paste your CSS into a validator like W3C CSS Validator or Stylelint before anything else. If the syntax is wrong, nothing else matters.
Fix 2: Add the Viewport Meta Tag (Often Missing in Custom Themes)
If your media queries work in a browser preview but fail on mobile, this is almost certainly why.
Without the viewport meta tag, mobile browsers render the page at desktop width and then scale it down. Your max-width: 768px rule never triggers because the browser thinks the viewport is 980px or 1024px.
Add this inside the <head> of your theme:
<meta name="viewport" content="width=device-width, initial-scale=1">In WordPress, that means editing your theme’s header.php or adding it via a hook:
function add_viewport_meta() {
echo '<meta name="viewport" content="width=device-width, initial-scale=1">';
}
add_action('wp_head', 'add_viewport_meta');Add this to your child theme’s functions.php or through a plugin like Code Snippets. Do not edit the parent theme directly — your changes will be overwritten on the next update.
Recommended if you’re seeing this issue on mobile only.
Fix 3: Check for CSS Specificity Conflicts
This is the sneaky one.
WordPress loads your theme’s stylesheet, then plugin stylesheets, then anything added via wp_enqueue_style(). If a plugin loads after your custom CSS with a more specific selector, your media query loses even if the syntax is perfect.
Open browser DevTools (F12 → Elements → Styles). Find the element that isn’t responding correctly. Look at which CSS rules are crossed out — those are being overridden.
If you see your media query rule crossed out with another rule below it, you have a specificity conflict. Three ways to fix it:
Option A — Increase specificity:
body .your-element {
font-size: 16px;
}Option B — Load your stylesheet later:
function load_custom_styles() {
wp_enqueue_style('custom-style', get_stylesheet_uri(), array('conflicting-plugin-style'), '1.0');
}
add_action('wp_enqueue_scripts', 'load_custom_styles');The third parameter lists dependencies — your stylesheet loads after them.
Option C — Use !important (see Fix 6 for when this is actually okay)
Fix 4: Use Browser DevTools to Diagnose — Not Guess
If you’re not using DevTools to debug CSS, you’re wasting time.
Open DevTools (F12 in Chrome, Firefox, Edge). Click the responsive design icon or press Ctrl+Shift+M. Set the viewport width to your breakpoint (e.g. 768px).
Now inspect the element that should be changing at that breakpoint. In the Styles panel, you’ll see exactly which CSS rules apply and which are overridden. This tells you:
- Whether your media query is being read at all
- Whether something else is overriding it
- What the computed styles actually are vs what you expect
One specific thing to check: the “Computed” tab shows the final applied values. If your font-size: 16px at mobile breakpoint isn’t showing up there, the issue is either syntax, specificity, or the file isn’t loading.
This step alone has saved me hours on client sites. Use it before trying any other fix.
Fix 5: Verify Your CSS File Is Actually Loading
Sometimes the file just isn’t there. Or isn’t being enqueued correctly.
In DevTools, go to Network and filter by CSS. Reload the page. Check whether your stylesheet appears in the list. Click it — confirm the media query code is actually in the file being served.
If the file isn’t loading, the issue is in how you’re registering it. The correct way to load custom CSS in WordPress:
function enqueue_custom_styles() {
wp_enqueue_style(
'my-custom-style',
get_stylesheet_directory_uri() . '/css/custom.css',
array(),
filemtime(get_stylesheet_directory() . '/css/custom.css')
);
}
add_action('wp_enqueue_scripts', 'enqueue_custom_styles');The filemtime() as the version parameter forces cache-busting every time the file changes. Caching is a silent killer for CSS updates in WordPress.
Also check file permissions: your CSS file should be readable (644). A permissions error can cause the file to 404 silently.
Fix 6: Use !important — But Only Here
!important gets a bad reputation because people abuse it. But there are two situations where it’s the right call.
One: you’re overriding third-party plugin styles and can’t change how they load. Two: you’re using the WordPress Customizer Additional CSS field, where specificity rules make normal overrides difficult.
@media screen and (max-width: 768px) {
.plugin-element {
display: none !important;
}
}If you’re reaching for !important everywhere, that’s a sign of a deeper architecture problem — your stylesheets are loading in the wrong order. Fix that first (Fix 3). But for a one-off override of a plugin style you can’t touch, !important inside your media query is fine.
FAQ
Why does my media query work in Chrome but not on my phone?
The viewport meta tag is missing. Mobile browsers need that tag to apply the correct viewport width. Without it, your breakpoints never trigger. Add Fix 2 above.
Why does my media query work on a plain HTML file but not in WordPress?
WordPress is loading another stylesheet after yours with higher specificity. Use DevTools (Fix 4) to find the conflicting rule, then fix the load order (Fix 3).
Does the WordPress block editor affect media queries?
Yes. The block editor injects its own stylesheet — wp-block-library — which sometimes sets styles that conflict with custom responsive rules. You can dequeue it if you’re not using blocks, or use specificity to override it.
My media query was working and then stopped. What happened?
Either a plugin update added a conflicting stylesheet, or a caching plugin is serving a stale version of your CSS. Clear all caches first. Then check DevTools to see if a new rule appeared that wasn’t there before.
Can I add media queries directly in the WordPress Customizer?
Yes, through Additional CSS. But the Customizer has lower specificity than stylesheets loaded via wp_enqueue_style. If something still overrides it, you’ll need !important (Fix 6) or move the CSS to a properly enqueued file.
If you’re still stuck after all six fixes, drop the issue in the comments. Share what the breakpoint is, what element isn’t responding, and what DevTools shows in the Styles panel. That’s usually enough to pinpoint it.
Need Help With Your WordPress Site?
I help with managed hosting, SEO content, speed optimization, security, and automation.
If your WordPress setup is giving you headaches — let me know.
