responsive CSS

Why Is My Website Zoomed Out on Mobile?

by

Website zoomed out on mobile problems usually happen when the browser is forced to fit a desktop-sized layout into a small phone viewport because of a missing viewport meta tag, fixed-width wrapper, wide grid, 100vw section, or mobile overflow.

Viewport Mobile Fix

Why is my website zoomed out on mobile?

A website looks zoomed out on mobile when the phone browser decides the page is wider than the screen and shrinks the whole layout to make it fit. The result is tiny text, tiny buttons, a desktop-looking page on a phone, or a layout that only becomes readable after the user manually zooms in.

Responsive Fixes HTML Fixes
  • Viewport meta tag
  • Fixed width bug
  • Mobile overflow
  • Responsive layout

What the bug looks like

The mobile page appears tiny, squeezed, or zoomed out, almost like the desktop site was pasted into a phone screen.

Why it happens

The viewport or layout width is wrong, so the browser scales the page instead of letting it flow responsively.

What usually fixes it

Add the correct viewport meta tag, remove fixed desktop widths, and fix the element causing horizontal overflow.

Error 1

The viewport meta tag is missing

This is the first thing to check when a website is zoomed out on mobile. The viewport meta tag tells the browser to use the device width as the layout width. Without it, mobile browsers may use a wider virtual canvas and shrink the page.

Broken code

Missing viewport 
<head>
  <title>My Website</title>
  <link rel="stylesheet" href="style.css">
</head>

Broken visual result

Tiny desktop page
zoomed out

Desktop layout

The browser is fitting a wide layout into a narrow phone screen.

The page looks tiny because the browser is not using the phone width correctly.

Correct code

Viewport added 
<head>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My Website</title>
  <link rel="stylesheet" href="style.css">
</head>

Fixed visual result

Real mobile width
normal scale

Mobile layout

The layout uses the actual device width and stays readable.

The browser now understands that the phone screen is the layout viewport.
Error 2

A fixed desktop wrapper is forcing the page wide

Even with the correct viewport tag, a fixed-width wrapper can still make the website feel zoomed out on mobile. If the main container is wider than the screen, the layout cannot shrink naturally.

Broken code

Fixed desktop width 
.page-wrapper {
  width: 1200px;
  margin-inline: auto;
}

Broken visual result

Forced desktop canvas
1200px wrapper

Wide wrapper

This container refuses to become smaller than desktop width.

The wrapper is wider than the phone, so the whole layout becomes difficult to read.

Correct code

Fluid container 
.page-wrapper {
  width: min(100% - 32px, 1200px);
  margin-inline: auto;
}

Fixed visual result

Fits the phone
fluid

Fluid wrapper

The container has a max width, but it can shrink on mobile.

A max-width pattern keeps desktop size without breaking mobile scale.
Error 3

The desktop grid never changes on mobile

A wide grid can make a mobile website look zoomed out because the browser is trying to keep multiple desktop columns alive inside a tiny viewport. The fix is not to shrink everything. The fix is to change the layout.

Broken code

Desktop grid only 
.cards {
  display: grid;
  grid-template-columns: repeat(3, 320px);
  gap: 24px;
}

Broken visual result

Columns stay too wide
desktop grid
Card 1

Too wide

Card 2

Too wide

Card 3

Too wide

The layout is still a desktop grid, so it behaves like a mini desktop page.

Correct code

Responsive grid 
.cards {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 24px;
}

@media (max-width: 700px) {
  .cards {
    grid-template-columns: 1fr;
  }
}

Fixed visual result

Mobile stack
responsive
Card 1

Readable width

Card 2

Readable width

Card 3

Readable width

On mobile, the layout changes shape instead of shrinking the desktop version.
Error 4

A hidden overflow element is making the viewport wider

Sometimes the page looks zoomed out on mobile because one element is secretly wider than everything else. It may be a long line of text, an image, a table, a button, a flex row, or a section using width:100vw with extra padding.

Broken code

Overflow created 
.hero {
  width: 100vw;
  padding-inline: 32px;
}

.long-link {
  white-space: nowrap;
}

Broken visual result

Hidden wide element
overflow

Wide section

A single element is wider than the viewport and pushes the layout.

One wide element can make the whole page behave like it is larger than the screen.

Correct code

Overflow-safe 
.hero {
  width: 100%;
  padding-inline: clamp(16px, 4vw, 32px);
}

.long-link {
  overflow-wrap: anywhere;
}

Fixed visual result

Viewport safe
no overflow

Safe section

The section respects the viewport and text can wrap safely.

The page keeps its normal mobile scale because no element escapes the viewport.
Premium pattern

A production-minded mobile viewport pattern

A stronger mobile layout starts in the HTML head, then uses flexible containers, safe media queries, and overflow-resistant children. The goal is simple: never make the browser choose between shrinking the page and creating sideways scroll.

Premium code

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

html,
body {
  width: 100%;
  max-width: 100%;
}

.wrapper {
  width: min(100% - 32px, 1120px);
  margin-inline: auto;
}

img,
video,
iframe {
  max-width: 100%;
  height: auto;
}

.card,
.grid,
.flex-row {
  min-width: 0;
}

.long-text {
  overflow-wrap: anywhere;
}

@media (max-width: 700px) {
  .desktop-grid {
    grid-template-columns: 1fr;
  }
}

Premium visual result

Readable mobile layout
clean scale
Hero section

Fluid, readable, and not wider than the phone.

Card
Card
Premium mobile layout does not depend on browser zoom tricks. It fits because the structure is built to fit.

Fast practical rule

If your website is zoomed out on mobile, check the viewport meta tag first. Then inspect the page for anything wider than the phone: fixed containers, grids, images, text, tables, buttons, flex rows, absolute elements, and 100vw sections.

Debug checklist

  • Confirm the page has <meta name="viewport" content="width=device-width, initial-scale=1">.
  • Look for wrappers using fixed widths like width:1200px.
  • Replace fixed containers with width:min(100% - 32px, value) or max-width.
  • Check whether the mobile media query is actually firing.
  • Inspect images, videos, iframes, tables, grids, buttons, and long text.
  • Search for 100vw sections with padding that may create extra width.
  • Use min-width:0 inside flex and grid children when content refuses to shrink.
  • Use overflow-wrap:anywhere for long strings, URLs, or unbroken text.
Best first move Check the viewport meta tag before changing CSS randomly.
Most common CSS cause A fixed desktop wrapper is wider than the phone screen.
Most hidden cause A single child element creates horizontal overflow and affects the whole page.
Better mindset Do not shrink the site. Make the layout naturally fit the viewport.

Related fixes that can help

A zoomed-out mobile site usually connects to viewport, overflow, container width, responsive breakpoints, or HTML structure problems.

Why is my page wider than the screen? If the mobile page looks zoomed out because one element is wider than the viewport. Read this fix
Horizontal scroll on mobile? If the page can move sideways or has a hidden overflow bug on phones. Read this fix
Fix responsive design not working If your mobile layout is not switching at the right breakpoint. Read this fix
Fix container width problems If wrappers, sections, or content blocks are forcing desktop width on mobile. Read this fix
Fix HTML structure problems If the layout is rigid because the page is wrapped or nested in the wrong structure. Read this fix
Why is my text overflowing outside the box? If a long word, URL, or text line is pushing the mobile viewport wider. Read this fix

Final takeaway

A website zoomed out on mobile is usually not a font-size problem. It is usually a viewport or layout-width problem. The browser is trying to fit a page that behaves wider than the device.

Start with the viewport meta tag, then find the element that is forcing the page wide. Once the page respects the mobile viewport, the text, buttons, grids, and sections become readable without forcing users to pinch zoom.

Want more fixes like this?

Browse more mobile layout, viewport, and responsive debugging guides in the FrontFixer library.

Responsive Fixes All Fixes

Why Is My Font Size Different on Mobile?

by

Font size different on mobile problems usually happen when desktop font sizes are too rigid, viewport units scale too aggressively, browser text adjustment changes the size, or media queries override typography unexpectedly.

Responsive Typography Fix

Why is my font size different on mobile?

Your text may look perfect on desktop, then suddenly become huge, tiny, cramped, or inconsistent on mobile. This usually happens because the font size is locked to a desktop value, tied too aggressively to viewport width, changed by a media query, affected by browser text scaling, or inherited from a parent you did not expect.

Responsive Fixes CSS Fixes
  • Responsive typography
  • clamp()
  • Viewport units
  • Mobile readability

What the bug looks like

Text becomes too large, too small, oddly spaced, hard to read, or different from the desktop design in a way that feels uncontrolled.

Why it happens

Typography is being controlled by a rigid value, an aggressive responsive value, inheritance, media query order, or browser text scaling.

What usually fixes it

Use a responsive type scale with clamp(), control line-height, avoid wild viewport units, and inspect the winning mobile rule.

Error 1

The desktop heading is too large for mobile

A big desktop heading can look premium on a wide screen, then become unreadable on a phone. Mobile typography needs its own scale or a fluid range.

Broken code

Desktop size everywhere 
.hero-title {
  font-size: 64px;
  line-height: 1;
}

Broken visual result

Too large
Fix the layout before it breaks

The heading dominates the screen and leaves little room for useful content.

The desktop font size is being forced into a mobile viewport.

Correct code

Mobile size controlled 
.hero-title {
  font-size: 64px;
  line-height: 1;
}

@media (max-width: 640px) {
  .hero-title {
    font-size: 32px;
    line-height: 1.08;
  }
}

Fixed visual result

Readable mobile scale
Fix the layout before it breaks

The heading still feels strong, but it now fits the mobile screen.

The mobile breakpoint gives the type a realistic phone-size value.
Error 2

Viewport units make the font scale unpredictably

Viewport units can be useful, but raw vw values can grow or shrink too aggressively. Without a minimum and maximum, the type can feel unstable across devices.

Broken code

Raw viewport units 
.section-title {
  font-size: 10vw;
  line-height: 1;
}

Broken visual result

No limits
Small screen: may still feel big Viewport math is doing all the work without guardrails.
Wide screen: can become huge The font keeps growing with the viewport.
Raw viewport units are often too loose for serious typography.

Correct code

Clamp the range 
.section-title {
  font-size: clamp(30px, 6vw, 56px);
  line-height: 1.05;
}

Fixed visual result

Controlled fluid scale
Small screen: protected minimum The title remains readable.
Large screen: controlled maximum The title grows, but does not explode.
clamp() gives the browser a safe minimum, flexible middle, and maximum.
Error 3

A mobile media query makes the font too small

Sometimes mobile text is different because someone intentionally changed it in a media query. The problem is not that mobile is random. The mobile rule is winning.

Broken code

Mobile rule too small 
.card-title {
  font-size: 28px;
}

@media (max-width: 640px) {
  .card-title {
    font-size: 14px;
  }
}

Broken visual result

Mobile rule wins badly
Important card title

The title becomes visually weak and harder to scan on mobile.

The media query is active, but the chosen value is too small.

Correct code

Mobile value still readable 
.card-title {
  font-size: 28px;
}

@media (max-width: 640px) {
  .card-title {
    font-size: 24px;
    line-height: 1.15;
  }
}

Fixed visual result

Mobile rule stays readable
Important card title

The title is smaller than desktop, but still readable and visually balanced.

Mobile typography should adapt without becoming tiny.
Error 4

em units inherit from a parent you forgot about

em units are relative to the parent font size. That can be useful, but it can also make text unexpectedly larger or smaller if a parent changes on mobile.

Broken code

Parent scale surprise 
.card {
  font-size: 14px;
}

.card-title {
  font-size: 2em;
}

Broken visual result

Relative to parent
Parent: 14px Title at 2em becomes 28px.
Parent changes: 18px Title at 2em becomes 36px.
The title changes because the parent changed, not because the title rule changed.

Correct code

Use rem or clamp 
.card-title {
  font-size: clamp(1.5rem, 5vw, 2rem);
  line-height: 1.1;
}

Fixed visual result

Predictable range
Minimum: 1.5rem The title does not collapse too small.
Maximum: 2rem The title does not grow out of control.
A controlled range makes the type easier to predict across layouts.
Premium pattern

A production-minded responsive type scale

A stronger typography setup uses fluid sizes with limits, sensible line-height, and predictable spacing. It keeps text readable without forcing one rigid size across every screen.

Premium code

Fluid but controlled 
:root {
  --step-title: clamp(2rem, 6vw, 4rem);
  --step-heading: clamp(1.5rem, 4vw, 2.4rem);
  --step-body: clamp(1rem, 2vw, 1.125rem);
}

.hero-title {
  font-size: var(--step-title);
  line-height: 1.02;
  letter-spacing: -0.04em;
}

.card-title {
  font-size: var(--step-heading);
  line-height: 1.12;
}

.body-text {
  font-size: var(--step-body);
  line-height: 1.75;
}

Premium visual result

Balanced type system
Responsive typography that still feels designed

The text scales with the screen, but the minimum and maximum values keep it under control.

Premium responsive typography is not random scaling. It is a controlled system.

Fast practical rule

If font size looks different on mobile, inspect the element and check the computed font size. Then look for the rule that wins on mobile: desktop value, media query, viewport unit, inherited parent size, or browser text adjustment.

Debug checklist

  • Inspect the element and check the computed font size on mobile.
  • Look for media queries that override the desktop font size.
  • Avoid using large desktop font sizes without a mobile adjustment.
  • Avoid raw viewport units like 10vw without minimum and maximum limits.
  • Use clamp() when you want fluid typography with guardrails.
  • Check whether em units are inheriting from a changed parent.
  • Adjust line-height along with font size.
  • Check browser text scaling only after CSS rules are confirmed.
Best first move Check the computed font size in DevTools instead of guessing from the visual result.
Most common cause A desktop heading size is being forced into a mobile viewport.
Most sneaky cause A parent font-size change affects child text that uses em.
Better mindset Responsive typography should be controlled by a type scale, not random breakpoint patches.

Related fixes that can help

If mobile font size looks wrong, the surrounding issue may involve responsive design, media queries, text overflow, or button text wrapping.

Why is my media query not working? If the mobile font rule does not seem to apply at the breakpoint. Read this fix
Why is my responsive design not working? If typography is only one symptom of a larger mobile layout problem. Read this fix
Why is my button text wrapping weirdly? If the font size looks wrong mainly inside CTA buttons. Read this fix

Final takeaway

Font size different on mobile is usually caused by a winning CSS rule, not by mystery. A desktop size may be too rigid, a viewport unit may be too aggressive, a media query may override the text, or a parent font size may affect child elements.

Start by checking the computed font size. Then build a controlled responsive type scale with sensible minimums, flexible middle values, and safe maximums. That gives your typography room to adapt without losing control.

Want more fixes like this?

Browse more responsive and CSS debugging guides in the FrontFixer library.

Responsive Fixes All Fixes

Why Does My Layout Shift by 1px at Certain Screen Widths?

by

A layout shift by 1px in CSS usually happens when the browser is forced to round fractional pixels, handle scrollbar width, calculate flexible columns, or switch between responsive rules at certain screen widths.

Responsive CSS Fix

Why Does My Layout Shift by 1px at Certain Screen Widths?

A layout shift by 1px can be hard to notice, but easy to feel. A card looks slightly off. A header no longer lines up with the content. A full-width section creates a tiny horizontal jump. The layout is not completely broken, but it feels unstable. The cause is usually CSS sizing math: 100vw, scrollbars, subpixel rounding, padding, borders, Grid, Flexbox, or a breakpoint that changes too much at once.

Browse All Fixes Explore CSS Fixes
  • 1px layout shift
  • Responsive CSS bug
  • Visual debugging

What the bug looks like

A container, card, navigation, button group, image area, or header moves slightly when the screen width changes.

Why it happens

CSS often calculates fractional widths, but the screen still has to paint real pixels. That conversion can expose tiny alignment issues.

What fixes it

Use safer width rules, stabilize scrollbars, apply consistent box sizing, and make Grid or Flexbox layouts more forgiving.

The FrontFixer visual rule for this bug

A 1px layout shift is easier to understand when you compare the code with what actually happens on the page. So this fix uses the same pattern for every common cause: first the broken code, then the broken visual result, then the corrected code, then the corrected visual result.

Use this mental model when debugging: the browser is not moving things randomly. Something in your CSS is creating a slightly different measurement than you expected.

Error 1

Using 100vw when the page needs 100%

One of the most common causes of a tiny layout shift is using width:100vw on a section that should simply follow the normal page width. On desktop, 100vw can include the scrollbar area. That means the section may become slightly wider than the content area.

Broken code

100vw trap 
.hero { width: 100vw; margin-left: calc(50% - 50vw); padding: 64px 24px; } .container { max-width: 1120px; margin: 0 auto; }

Broken visual result

Section is too wide
Hero uses 100vw The section pushes slightly outside the normal page alignment.
The section looks almost correct, but it is wider than the content area.

Correct code

Safer width 
.hero { width: 100%; padding: 64px 24px; } .container { width: min(100% - 32px, 1120px); margin-inline: auto; }

Fixed visual result

Section is aligned
Hero uses normal flow The section now follows the same width system as the rest of the page.
The content edge and section edge now agree with each other.
Error 2

Forgetting box-sizing:border-box

Another common cause of small layout movement is the box model. If you give an element a width and then add padding and border, the final rendered size can become larger than expected. Sometimes the overflow is obvious. Other times it starts as a tiny visual mismatch.

Broken code

Width plus padding 
.card { width: 300px; padding: 24px; border: 1px solid #ddd; }

Broken visual result

Card becomes wider
Card width is not what you expected Padding and border are added on top of the declared width.
This can make one card appear slightly wider than the others.

Correct code

Stable box model 
*, *::before, *::after { box-sizing: border-box; } .card { width: 300px; padding: 24px; border: 1px solid #ddd; }

Fixed visual result

Card stays inside
Card size is predictable Padding and border are included inside the declared width.
The card now follows a more predictable sizing system.
Error 3

Letting Grid and Flexbox fight fractional pixels

Grid and Flexbox distribute available space. If the available width does not divide cleanly, the browser has to decide where the leftover pixel goes. That is why one column, tab, or button can sometimes look one pixel wider or slightly off.

Broken code

Tight grid math 
.grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 9px; } .card { min-width: auto; }

Broken visual result

One column feels off
With tight spacing, fractional distribution becomes visually easier to notice.

Correct code

Safer grid 
.grid { display: grid; grid-template-columns: repeat(3, minmax(0, 1fr)); gap: 24px; } .grid > * { min-width: 0; }

Fixed visual result

Grid feels stable
The grid has more predictable tracks and children are allowed to shrink.
Error 4

Making breakpoints too jumpy

Sometimes the 1px shift is not really a rounding issue. It is a breakpoint issue. The layout changes at a specific width, and that change makes the page look like it jumped. This is common around widths like 1366px, 1280px, 1024px, or any custom breakpoint.

Broken code

Jumpy breakpoint 
.container { max-width: 1200px; padding-inline: 32px; } @media (max-width: 1366px) { .container { max-width: 1180px; padding-inline: 31px; } }

Broken visual result

Breakpoint jump
1367px
1366px
The layout changes too much right when the viewport crosses the breakpoint.

Correct code

Fluid container 
.container { width: min(100% - 32px, 1200px); margin-inline: auto; }

Fixed visual result

Smooth resizing
1367px
1366px
One clear formula creates a smoother transition between screen widths.
Error 5

Ignoring scrollbar appearance and disappearance

A layout can shift when the vertical scrollbar appears or disappears. This often happens when a modal opens, content loads, tabs switch, accordions expand, or a page changes from short to scrollable. The content area becomes slightly different, and centered elements can appear to move.

Broken code

No scrollbar stability 
html { overflow-y: auto; } .modal-open { overflow: hidden; }

Broken visual result

Scrollbar changes width
Centered content moved The available page width changed when the scrollbar appeared or disappeared.
The layout may jump even when your container CSS looks correct.

Correct code

Stable gutter 
html { scrollbar-gutter: stable; } /* Test browser support for your audience. */

Fixed visual result

Scrollbar space is reserved
Content stays stable The browser keeps space for the scrollbar, reducing horizontal jumps.
This can help when the shift happens because scrolling state changes.

Fast practical rule

If your layout shift is only 1px, do not patch it with margin-left:-1px or random transforms first. A tiny visual bug usually has a tiny math cause: 100vw, scrollbar width, fractional columns, box sizing, padding, borders, or a breakpoint that changes the layout too sharply.

How to debug the exact layout shift

Start by resizing the browser slowly. Watch the exact width where the layout shift appears. If it happens around a breakpoint, inspect the media query. If it happens when the page becomes scrollable, inspect scrollbar behavior. If it happens across many widths, look for fractional Grid, Flexbox, or percentage math.

Then inspect the element that moved. Check its computed width, margin, padding, border, transform, and parent container. The goal is to find which measurement changed by that tiny amount.

Temporary debug CSS

Debug only 
* { outline: 1px solid rgba(255, 0, 0, 0.15); } html, body { overflow-x: clip; }

Use outlines temporarily to see which element is wider or misaligned. Remove debug outlines before shipping the page.

Debug checklist

  • Check whether any section uses width:100vw when width:100% would be safer.
  • Check if the layout shifts when the vertical scrollbar appears or disappears.
  • Add box-sizing:border-box globally if the project does not already use it.
  • Inspect the exact viewport width where the 1px shift starts.
  • Look for media queries that change padding, gap, max width, or column count at that width.
  • Check if Grid columns use plain 1fr where minmax(0,1fr) would be safer.
  • Add min-width:0 to flex or grid children that contain long content.
  • Avoid fragile combinations of calc(), percentage widths, borders, and fixed gaps when the layout must align perfectly.
  • Test common desktop widths like 1366px, 1440px, and 1920px.
  • Do not hide the problem with random negative margins unless you have identified the real cause.
Best first move Replace unnecessary 100vw usage with 100% and retest.
Most common false fix Adding margin-left:-1px without understanding why the layout moved.
Most overlooked cause Scrollbar width changing the available content area.
Better mindset A 1px layout shift is usually a sizing-system problem, not a random browser attack.

Related fixes that can help

If your 1px layout shift is part of a wider responsive or overflow issue, these FrontFixer guides are the next places to check.

Fix container width problems If your page feels too wide, too narrow, or misaligned between sections. Read this fix
Fix overflow causing horizontal scroll If the 1px issue is actually a hidden overflow problem on mobile or desktop. Read this fix
Fix CSS Grid breaking on mobile If fractional columns, rigid tracks, or long content are making the grid unstable. Read this fix

Final takeaway

A layout shift by 1px at certain screen widths usually comes from CSS sizing math. The most common causes are 100vw, scrollbar width, subpixel rounding, fractional Grid or Flexbox distribution, padding, borders, and breakpoint rules that change too much at once.

Start with the simple checks: avoid unnecessary 100vw, use box-sizing:border-box, stabilize your container formula, inspect breakpoints, and reduce layout pressure inside Grid and Flexbox. Once the sizing system becomes predictable, the tiny 1px shift usually disappears.

Want more fixes like this?

Explore the full FrontFixer fixes library and keep debugging with practical guides built for real front-end layout problems.

Browse All Fixes Explore CSS Fixes
“`

Why Is My Media Query Not Working?

by

Media query not working problems usually happen when the browser is reading a different viewport, a different CSS rule, or a more rigid layout than the one you think you are testing.

Responsive CSS Fix

Why is my media query not working?

If your mobile styles are not applying, your breakpoint seems ignored, or your layout stays stuck in desktop mode, the browser is usually not being random. The real issue is usually a missing viewport tag, invalid syntax, CSS order, specificity, cache, or a rigid layout that makes the media query look broken even when it is actually firing.

Browse Responsive Fixes Browse All Fixes
  • Viewport setup
  • Breakpoint logic
  • CSS cascade
  • Rigid layout traps

What the bug looks like

Your CSS says mobile should be one column, but the page stays in desktop mode. Or your media query changes one thing, but the layout still overflows and looks broken.

Why it happens

A media query does not magically make a layout responsive. It only applies CSS under a condition. If setup, cascade, or structure is wrong, the result still breaks.

What usually fixes it

Confirm the viewport tag, test the breakpoint in DevTools, inspect overridden rules, then replace rigid layout rules with flexible responsive patterns.

Error 1

Missing viewport tag makes mobile CSS look ignored

This is one of the most common reasons a media query does not work on mobile. Without the viewport meta tag, the browser may render the page as a wide desktop canvas and scale it down. Your breakpoint may not match the real screen the way you expect.

Broken code

Missing viewport 
<head>
  <title>My Page</title>
  <link rel="stylesheet" href="style.css">
</head>

@media (max-width: 768px) {
  .cards {
    grid-template-columns: 1fr;
  }
}

Broken visual result

Mobile acts like desktop
Card 1
Card 2
Card 3
The page is still behaving like a wide desktop canvas, so the mobile layout feels ignored.

Correct code

Real mobile viewport 
<head>
  <meta name="viewport"
        content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="style.css">
</head>

@media (max-width: 768px) {
  .cards {
    grid-template-columns: 1fr;
  }
}

Fixed visual result

Viewport matches device
Card 1
Card 2
Card 3
The browser now treats the screen as a real mobile viewport, so the breakpoint can behave correctly.
Error 2

Invalid media query syntax silently breaks the rule

Media query syntax is easy to almost get right. A missing space, missing unit, wrong parenthesis, or forgotten brace can make the browser skip the rule or read it differently than you intended.

Broken code

Syntax trap 
@media screen and(max-width: 768px) {
  .menu {
    display: none;
  }

  .cards {
    grid-template-columns: 1fr;
  }
}

Broken visual result

Breakpoint ignored
Desktop nav still visible
Card
Card
Card
The CSS looks close, but the condition is malformed, so the mobile rule does not behave as expected.

Correct code

Valid condition 
@media screen and (max-width: 768px) {
  .menu {
    display: none;
  }

  .cards {
    grid-template-columns: 1fr;
  }
}

Fixed visual result

Mobile rule applies
Compact mobile header
Card 1
Card 2
Card 3
The same layout now stacks because the media query condition is valid and readable.
Error 3

The media query works, but CSS order overrides it

The browser may be applying your media query correctly, then immediately replacing it with a later rule. This is why media queries can “work” in DevTools but still not change what you see on the page.

Broken code

Later desktop rule wins 
@media (max-width: 768px) {
  .card-title {
    font-size: 18px;
  }
}

.card-title {
  font-size: 36px;
}

Broken visual result

Mobile rule crossed out

Huge title on mobile

The media query fires, but the later desktop rule wins the cascade.

@media font-size: 18pxoverridden
later font-size: 36pxwins

Correct code

Mobile rule comes after 
.card-title {
  font-size: 36px;
}

@media (max-width: 768px) {
  .card-title {
    font-size: 22px;
  }
}

Fixed visual result

Mobile rule wins

Readable mobile title

The mobile rule appears later, so the cascade now matches the responsive intention.

base font-size: 36pxbase
@media font-size: 22pxwins
Error 4

The breakpoint fires, but the layout is still rigid

This is the grown-up version of the media query bug. The media query is not dead. The layout is still too rigid. A fixed-width wrapper, a wide grid, a long code block, or an image without responsive limits can make the page look broken even after the breakpoint activates.

Broken code

Breakpoint fires, layout still breaks 
.wrapper {
  width: 1200px;
}

.cards {
  display: grid;
  grid-template-columns: repeat(3, 320px);
}

@media (max-width: 768px) {
  .cards {
    grid-template-columns: 1fr;
  }
}

Broken visual result

The wrapper is still 1200px
Mobile breakpoint active
Wide wrapper
Still overflowing
Not responsive
The media query changed the grid, but the parent still forces a desktop width.

Correct code

Flexible parent and grid 
.wrapper {
  width: min(100%, 1200px);
  margin-inline: auto;
  padding-inline: 16px;
}

.cards {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 24px;
}

@media (max-width: 768px) {
  .cards {
    grid-template-columns: 1fr;
  }
}

Fixed visual result

Parent can shrink
Responsive layout
Card 1
Card 2
Card 3
Now the wrapper and grid both cooperate with the breakpoint.
Premium pattern

A production-minded media query setup

The best responsive fix is not just one media query. It is a layout system that starts flexible, uses safe grid tracks, lets children shrink, protects images, and only uses breakpoints to adjust behavior—not to rescue broken desktop code.

Premium code

Flexible first 
.layout {
  width: min(100%, 1120px);
  margin-inline: auto;
  padding-inline: clamp(16px, 4vw, 32px);
}

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 240px), 1fr));
  gap: clamp(16px, 3vw, 28px);
}

.card,
.card * {
  min-width: 0;
}

.card img {
  display: block;
  max-width: 100%;
  height: auto;
}

@media (max-width: 768px) {
  .layout {
    padding-inline: 16px;
  }

  .card-title {
    font-size: clamp(24px, 8vw, 34px);
  }
}

Premium visual result

Flexible before breakpoint
Production-ready cards
Safe card width
No overflow trap
Breakpoint becomes lighter
The layout is responsive even before the media query has to do heavy work.

Fast practical rule

If your media query is not working, do not start by changing random breakpoint numbers. First confirm the viewport tag, then test whether the rule is firing in DevTools, then check whether another rule or a rigid parent is still winning.

Debug checklist

  • Confirm the page includes <meta name="viewport" content="width=device-width, initial-scale=1">.
  • Resize the page in DevTools and confirm whether the media query is actually firing.
  • Check the media query syntax for missing spaces, braces, parentheses, units, and invalid conditions.
  • Inspect whether a later CSS rule is overriding the media query.
  • Check whether a stronger selector is beating your mobile selector.
  • Verify whether the breakpoint should use max-width or min-width.
  • Look for a fixed-width wrapper, wide grid track, long word, code block, image, table, or child element that refuses to shrink.
  • Clear browser, plugin, and CDN cache if your CSS changes are not showing at all.
Best first move Use DevTools to see whether the media query is active before changing the breakpoint value.
Most overlooked cause The viewport tag is missing, so the browser never behaves like the real mobile screen.
Most frustrating cause The media query works, but a later CSS rule silently overrides it.
Better mindset Media queries should tune a flexible layout, not save a layout that was built rigid from the beginning.

Related fixes that can help

If your media query fires but the layout still breaks, the real cause may be responsive structure, overflow, Grid sizing, or a hidden fixed-width child.

Fix responsive design not working If the entire page still feels stuck in desktop mode after your breakpoint fires. Read this fix
Fix overflow causing horizontal scroll If one hidden wide element makes the mobile layout look broken. Read this fix
Fix CSS Grid breaking on mobile If Grid tracks still demand more width than the screen can give. Read this fix

Final takeaway

A media query not working rarely means the browser is broken. Most of the time, the browser is following the rules exactly: the viewport is wrong, the condition is invalid, the cascade is overriding the rule, specificity is too strong, cache is stale, or the layout is still too rigid to respond.

Start by proving whether the media query is active. Then debug the cascade. Then fix the structure. Once the layout is flexible first, media queries become precise adjustments instead of emergency rescue patches.

Want more fixes like this?

Browse more responsive debugging guides or jump to the full FrontFixer library.

Responsive Fixes All Fixes