Give your WordPress site its first task.
Connect the site you already have, add your agent to Slack or Telegram, and tell it what you need.
Connect your siteStart with 500 free credits. No credit card needed.
A mobile media query checks the width of the browser viewport. It does not detect phones, and no breakpoint is the official mobile one. On WordPress the query itself rarely fails. The usual problem is cached CSS, a builder setting, a selector that loses, or CSS pasted into the wrong field.
A common snippet for mobile CSS is @media (max-width: 767px) { ... }. It applies its rules when the viewport is 767 CSS pixels wide or narrower. That includes a phone, and it also includes a laptop browser window dragged narrow. The number is a convention, not a standard.
On WordPress sites, people usually notice this when a mobile fix looks right in the editor and wrong on their phone. Most of the time the media query is fine. Something else wins: a cached stylesheet, a builder setting, or a more specific selector. This guide covers how to write the query, where to put it, and how to find the actual cause when it doesn’t apply.
A media query is a condition. The browser checks it and applies the rules inside only when it is true. For layout, that condition is almost always the viewport width in CSS pixels. Elementor’s responsive editing docs make the same point: a breakpoint applies to any screen at that width, whatever the device.
You can write the condition in two directions:
/* Desktop-first: base styles are for wide screens, this overrides them on narrow ones */
@media (max-width: 767px) {
.site-columns { flex-direction: column; }
}
/* Mobile-first: base styles are for phones, this adds layout on wider screens */
.site-columns { display: flex; flex-direction: column; }
@media (min-width: 768px) {
.site-columns { flex-direction: row; }
}
Use width, max-width and min-width. Avoid max-device-width. It measures the physical screen rather than the viewport the page is laid out in, so it can disagree with what visitors actually see. If you want the bigger picture of how themes and builders split layout control, start with how layout works on WordPress.
No single number is correct. Media queries test conditions, and the familiar values come from tool defaults:
| Source | Mobile | Tablet |
|---|---|---|
| WordPress responsive styles (block themes, WordPress 7.1+) | 480px and below | Up to 782px |
| Elementor defaults | 767px | 1024px |
| Common desktop-first CSS | max-width: 767px | Varies by theme |
MDN recommends adding a breakpoint where the layout starts to fail, not at a device size. Drag the browser narrower until something looks cramped, overlaps or overflows, and put the breakpoint just above that width. WordPress’s CSS Coding Standards say to test above and below every breakpoint you add.
There is one practical exception. If the page is built in Elementor, or a block theme uses responsive styles, use that tool’s breakpoint for your custom CSS too. If your CSS switches at 600px and the builder switches at 767px, the layout spends 167 pixels half-converted.
Without a viewport meta tag, mobile browsers can lay the page out on a wider virtual viewport and then shrink it to fit. The W3C CSS Viewport spec describes this older behaviour. When it happens, your max-width: 767px query never matches, and changing the number won’t fix it.
Open the live page, view the source, and search for viewport. You want something like:
<meta name="viewport" content="width=device-width, initial-scale=1">
Almost every current theme outputs this already, so check before you add one. A duplicate tag won’t help. If the existing tag contains user-scalable=no or maximum-scale=1, it is stopping visitors from zooming. Fixing that belongs in the theme or a child theme, not in Additional CSS.
You need an administrator login and a desktop browser with developer tools. Chrome, Firefox and Edge all work.
Here is a real case. In a WooCommerce support thread, a store owner’s Add to Cart button looked fine on a laptop and wrong on phones. The fix was to wrap the button styles in a 600px query, which made the button full width with a smaller font. The owner replied “It worked perfectly.” The pattern looks like this:
@media (max-width: 600px) {
.single_add_to_cart_button.button.alt {
display: block;
width: 100%;
font-size: 14px;
}
}
Watch out for the second CSS field. Each block type in the Styles panel also has its own Additional CSS box, and WordPress’s Styles documentation says it takes declarations only, with no selectors and no braces. A full @media rule pasted there will not work. Also note that Additional CSS survives theme updates but is cleared when you switch themes. Keep a copy, and move anything substantial into a child theme. The guide to theme customization that survives updates covers which layer to choose.
Many mobile problems are overflow, not layout. These rules fix a lot of them without a breakpoint:
img, video, iframe { max-width: 100%; height: auto; }
.entry-content { overflow-wrap: break-word; } /* long URLs */
h1 { font-size: clamp(1.75rem, 5vw, 3rem); } /* fluid heading */
.card-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
}
Keep media queries for changes that are real layout shifts: switching the menu, stacking columns, reflowing a table, showing or hiding a secondary element. Use fluid sizing for everything else.
The rule should apply at every width below your breakpoint and at none above it. Check it in the device toolbar at 320, 375 and 414 pixels, then just above and just below the breakpoint. At 320 CSS pixels, nothing should scroll sideways and nothing should be cut off. That width comes from WCAG 1.4.10 Reflow, which asks that vertically scrolling content keep all its information and functions at that width without two-dimensional scrolling.
Then open the page on a real phone in a private tab. Builder device previews are not always a real viewport. A Stack Exchange question about Gutenberg’s preview describes it narrowing the container instead, so a rule can pass in preview and fail on the phone.
These causes come up again and again in WordPress support threads. They are listed roughly from most to least often reported. This order comes from reading the threads, not from a survey.
Page builders write CSS to files, and caching or optimization plugins combine and minify those files. Your edit saves, but the phone receives the previous version. In Elementor, go to Elementor > Editor > Tools and run Clear Files & Data. Then clear the caching plugin, then the host or CDN cache, then the browser cache. In one resolved LiteSpeed Cache thread, GeneratePress’s dynamic CSS kept being served stale on mobile until the affected files were excluded from CSS optimization. If a purge doesn’t stick, the guide to pages that won’t update walks through each cache layer.
Elementor’s mobile troubleshooting guide lists the usual suspects. They are Advanced > Responsive > Hide On, widget-level Custom CSS, site-wide custom code, and theme or plugin conflicts. Some older themes and plugins also serve a separate mobile theme. Turn it off before you debug CSS that the phone never loads.
Builders wrap each widget in several divs, so a selector copied from a tutorial often matches nothing. Copy the class from the live page in DevTools. If the selector matches but loses, put your rule after the base rule, or make it a little more specific. Add !important only when the rule you are overriding already uses it. If you add !important to everything, the next fix gets harder.
CSS doesn’t show errors. A missing closing brace can swallow every rule after it. In one WordPress.com forum case, the query said screen2 instead of screen. Sydney theme support told another user that an invalid line in Additional CSS can stop the lines after it from working. Paste your CSS into a validator, or check that DevTools lists your rule at all.
Media queries in the per-block field, CSS inside a page’s content, or a stylesheet that isn’t enqueued on that template all look like “mobile CSS not working”. In DevTools, check that your rule is present in the Styles panel at a phone width.
Get help if you have ruled out all five and the rule still doesn’t apply. Builder plugins have their own bugs. Elementor Pro 3.24.5, for example, fixed responsive styles not loading in Apple’s WebKit. Some threads never find a root cause. Gather the page URL, the width where it breaks, the element and the winning rule from DevTools, and send them to the theme or plugin’s support. If you would rather describe the problem than track it down, SiteSelf can make theme-level design and mobile styling changes on request from chat, with hosting access. Pages owned by Elementor, Divi or Beaver Builder are refused, and you are told why.
The easy mobile fix is display: none. It also removes the element for screen readers. Google indexes and ranks the mobile version of a page and advises against removing primary content there. Accordions and tabs are fine. Hiding a decorative image or a duplicate call to action is fine. Hiding prices, product details or the text that explains your offer is not.
Follow the theme you have. Most themes are written desktop-first, so small fixes are easiest as max-width overrides. If you are building a new section from scratch, mobile-first with min-width keeps phone styles simple. The cost is resetting some of them on wider screens.
Fewer of them. Fluid type and auto-fit grids handle much of the resizing that used to need breakpoints. You still need queries for real layout changes, such as switching to a mobile menu or reflowing a table.
It depends on the theme. Some themes have a setting for it. Others hard-code the breakpoint in their navigation CSS, so you have to override those rules at the width you want. Check your theme’s documentation or support forum before writing an override.
Container queries style an element based on the size of its parent rather than the viewport. That suits blocks that appear in both sidebars and full-width areas. They are a reasonable choice for custom components you write yourself, but most WordPress themes still use viewport media queries.
The rule probably sits outside any media query, or inside the wrong one. Wrap the declarations in the mobile query and check the closing braces. A rule with no query applies at every width.
How-to Tutorials
A WordPress restore puts back two things together: the files and the database, both from the same moment. It also wipes out everything that happened after that moment. So before you click Restore, check what the backup actually contains and save anything newer, and after it finishes, check the site before you trust the “complete” message.
Read article ›How-to Tutorials
WordPress has no single switch that password-protects a whole website. The built-in setting covers one post or page, a whole-site lock needs a plugin or your host’s password tool, and uploaded files usually stay public unless you protect them at the server. Pick the method that matches what you are protecting, then test it logged out with caching in mind.
Read article ›How-to Tutorials
To hide a WordPress page title, hide the heading the theme prints. Leave the title stored on the page alone. Which control does that depends on your theme, your template and whether a page builder or WooCommerce owns the page. So start by finding which element is actually showing, then use the most built-in control you have.
Read article ›Connect the site you already have, add your agent to Slack or Telegram, and tell it what you need.
Connect your siteStart with 500 free credits. No credit card needed.