Why Your “Responsive” Site Still Breaks on Mobile (Even With Media Queries)

A responsive page is not defined by the number of media queries in its stylesheet. It is defined by whether content, controls, media, and reading order remain usable as the available space changes. A page can contain correct-looking breakpoints and still fail because the viewport is misreported, a child has an unshrinkable width, an image overflows, or the visual order no longer matches the reading order.

The symptom: your media queries exist, but never seem to trigger

Here’s the part that trips people up first. You write a media query at max-width: 480px, assuming it fires once the screen gets that narrow. On a real phone with a screen that’s genuinely around 390px wide, it still doesn’t trigger — the layout stays in its desktop shape, just shrunk down and zoomed out.

@media (max-width: 480px) {
  .sidebar { display: none; }
}

This isn’t a bug in your CSS. It’s a browser doing exactly what it was designed to do — just not what you assumed.

The real cause: mobile browsers lie about their own width

According to MDN’s documentation on the viewport meta tag, mobile browsers historically render pages inside a virtual viewport around 980px wide — regardless of the phone’s actual screen size — and then shrink the whole result down to fit. This existed specifically to make old, non-mobile-optimized sites look less broken by default, back before responsive design was common. The side effect: a media query set to trigger at 480px is comparing against that fake 980px virtual width, not your phone’s real 390px, so it simply never fires. This isn’t a fringe browser quirk left over from one specific device — it’s the default behavior baked into how mobile rendering engines have worked since smartphones first needed to display websites that were never designed with them in mind.

<meta name="viewport" content="width=device-width, initial-scale=1">

This single line is what tells the browser to stop lying — to report its actual device width instead of the historical 980px default. Without it, every media query you write is being evaluated against a number that has nothing to do with the screen in front of the user.

What happens once the viewport is honest

With the meta tag in place, your 480px media query is now being compared against the phone’s real width, and it fires exactly where you expected. But fixing the viewport lie doesn’t automatically fix everything — it just makes your media queries trustworthy. What they do once they trigger is a separate problem, and it’s the one most tutorials treat as an afterthought.

The second, quieter cause: content that “fits” but doesn’t actually reflow

Even with an honest viewport, a page can still look broken in a specific, less obvious way: elements with a fixed pixel width that simply don’t shrink, forcing horizontal scroll even though nothing visually overflows the way you’d expect.

/* Breaks reflow: a hard-coded width that ignores the container */
.hero-image {
  width: 800px;
}

/* Reflows correctly: scales down instead of overflowing */
.hero-image {
  max-width: 100%;
  height: auto;
}

The responsive web design basics guide from web.dev specifically calls out fixed-width images as one of the most common sources of this exact failure — an image sized in hard pixels doesn’t know how to shrink to fit a container narrower than itself, so it just spills past the edge, dragging a horizontal scrollbar along with it.

Why does this “less obvious” failure matter as much as the viewport one?

Because it’s the one that survives even after a developer does everything “right.” You can have the correct viewport tag, correctly triggering media queries, and still ship a page that technically responds to screen size while still feeling broken — a sidebar that hides on mobile per your media query, but a product image inside the remaining content that refuses to shrink below 800px, quietly reintroducing the exact horizontal-scroll problem the media query was supposed to prevent.

A third layer almost nobody mentions: reflow order versus reading order

There’s a failure mode that survives even a perfectly reflowing, non-scrolling layout: CSS can visually reorder elements — moving a sidebar above the main content on mobile, for instance — without changing the order those elements actually exist in the HTML. Visually, it looks correct. For anyone navigating by keyboard or using a screen reader, the experience jumps around in an order that no longer matches what’s on screen, because those tools follow the underlying document structure, not the final visual arrangement.

<!-- Visually reordered with CSS, but DOM order stays the same -->
<div class="layout">
  <aside class="sidebar">...</aside>
  <main>...</main>
</div>

.layout {
  display: flex;
  flex-direction: column-reverse; /* main now appears first, visually */
}

This particular bug is easy to miss because it only shows up for a subset of visitors, and it requires deliberately testing without a mouse to notice at all — a purely visual review of the finished page will never surface it, no matter how many times you resize the browser window and check that everything looks correctly stacked.

The MDN guide to responsive web design frames responsive design as building sites that respond to the environment they’re viewed in — and a screen reader’s linear reading order is just as much a part of that environment as a phone’s screen width, even though it’s the part almost no beginner checklist mentions.

Putting the three layers together

A genuinely responsive page needs all three, in order: an honest viewport so your media queries fire against real numbers, content that actually reflows instead of overflowing at fixed widths, and a DOM order that still makes sense when the visual order changes. Skipping the first makes your media queries irrelevant. Skipping the second makes them fire against a layout that still breaks anyway. Skipping the third means the page can pass every visual check you run yourself, while still being confusing or unusable for someone navigating it in a completely different order than what they see.

Watching all three fail — and get fixed — on one page

Picture a simple article page: a header, a sidebar with related links, and the main article content. Here’s the layout with all three problems present at once:

<!-- head is missing the viewport meta tag entirely -->
<div class="layout">
  <aside class="sidebar">...</aside>
  <main>
    <img src="hero.jpg" width="800">
    <p>Article content...</p>
  </main>
</div>

.layout { display: flex; }
@media (max-width: 480px) {
  .layout { flex-direction: column-reverse; }
}

On a phone, this page loads zoomed out (no viewport tag, so the browser assumes 980px). Even if you zoom in manually, the 800px-wide image forces horizontal scrolling no matter how narrow the screen gets. And because column-reverse only changes the visual stacking order, a keyboard or screen-reader user still encounters the sidebar’s links before the actual article content, even though visually the article now appears on top.

<!-- viewport tag added to the head -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- DOM order swapped so main comes first structurally, not just visually -->
<div class="layout">
  <main>
    <img src="hero.jpg" style="max-width: 100%; height: auto;">
    <p>Article content...</p>
  </main>
  <aside class="sidebar">...</aside>
</div>

.layout { display: flex; flex-direction: column; }

Three small changes, each fixing a different layer: the viewport tag makes media queries trustworthy, max-width: 100% makes the image actually reflow instead of overflowing, and reordering the HTML itself (instead of only reordering visually with CSS) means the structure a screen reader or keyboard user experiences now matches what’s visually on screen. None of the three fixes would have been enough on its own — the page would have kept failing in whichever layer was still untouched.

A quick way to check your own page for all three

Open your page on an actual phone, not just a resized browser window — the built-in device emulator in browser dev tools is a reasonable stand-in if a real phone isn’t available. First, confirm nothing looks zoomed out at load (viewport). Second, resize slowly and watch for anything that stays a fixed size while everything around it shrinks (reflow). Third, navigate the page using only the Tab key and check whether the order you move through it in still makes logical sense compared to what’s visually on screen (reading order).

Each check takes under a minute, and each one catches a failure the other two can’t. A page can pass the viewport check and still have a horizontally-scrolling image. It can pass both the viewport and reflow checks and still send a keyboard user through the sidebar before the article they came to read. Running all three, every time you finish a layout, catches the specific combination of symptoms that “just looking at it on my laptop” almost never reveals — your own browser window is rarely narrow enough, and your own laptop trackpad rarely simulates Tab-key navigation the way an actual visitor relying on it would experience the page.

Frequently Asked Questions

Do I need a different viewport meta tag for every page?
No — the standard width=device-width, initial-scale=1 tag works the same way across virtually every page and doesn’t need to change based on content.

Does mobile-first design solve the reflow problem automatically?
It reduces the risk, since you’re writing base styles for small screens first, but it doesn’t guarantee it — a fixed-width element added later can still break reflow regardless of which approach you started from.

Can I test reading order without a screen reader?
Yes, to a reasonable degree — navigating your page with only the Tab key reveals the same underlying DOM order a screen reader would follow, even without installing or learning a dedicated screen reader tool.

Is it ever acceptable to disable zooming with the viewport tag?
Generally no — restricting user-scalable or setting a fixed maximum-scale blocks people who rely on zooming to read text comfortably, which trades one accessibility problem for another.

Related: if the DOM-versus-visual-order issue above was new to you, our HTML basics guide covers how document structure works before any CSS gets involved.

Use a failure matrix instead of guessing breakpoints

When a page breaks on a phone, identify the first visible failure and test the smallest responsible layer. Responsive design is an approach built from fluid layout, media queries, flexible grids, responsive media, and the viewport configuration [1]. A breakpoint should respond to the content becoming unusable, not to a favorite device list.

Test the viewport and the content separately

The viewport meta element solves one class of mobile interpretation problems, but it cannot repair a fixed-width child. Use browser DevTools to inspect the document width, then search for elements whose scroll width exceeds their container. Check tables, code blocks, embedded media, absolute positioning, long unbroken strings, and flex items with an unintended minimum width.

const pageWidth = document.documentElement.scrollWidth;
const viewportWidth = document.documentElement.clientWidth;
console.log({ pageWidth, viewportWidth, overflow: pageWidth - viewportWidth });

This diagnostic is evidence, not a permanent fix. Removing overflow from the body can hide the symptom while leaving content inaccessible. The goal is to find the element that cannot reflow, then decide whether it should wrap, scroll within its own region, stack, resize, or be replaced with a more suitable representation.

Keep source order meaningful

CSS Grid and Flexbox can change visual placement, but a visual arrangement is not automatically a good reading order. Screen readers, keyboard users, copied text, and narrow layouts may follow the document order. Place headings, navigation, main content, and supporting information in a sensible source sequence before using visual reordering. A mobile layout is more robust when its HTML remains understandable without the desktop arrangement.

Responsive review checklist

• Confirm the mobile viewport is declared correctly.
• Test narrow and wide widths, not only familiar device presets.
• Find the first element that creates horizontal overflow.
• Check images, tables, code, embeds, long words, and flex/grid minimum sizes.
• Use content-driven breakpoints and prefer fluid layout where possible.
• Test keyboard focus, touch targets, zoom, and source reading order.
• Verify that a visual fix did not hide content from assistive technology.

For related foundations, see Vandutz guides to CSS basics, HTML structure, and adding JavaScript to HTML. A responsive page is a system that continues to communicate as its constraints change, not a collection of device-specific patches.

Alex Carter

Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.