FrontFixer

Why Is My Media Query Not Working?

by

Responsive Fix

Why is my media query not working even though the CSS looks right?

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 problem is usually a missing viewport tag, invalid syntax, CSS specificity conflicts, wrong rule order, a typo, or a layout issue that makes the media query look broken.

Browse Responsive Fixes See the Difference
  • Classic responsive bug
  • Usually a setup or cascade issue
  • Often fixed fast once diagnosed

What the bug looks like

The breakpoint seems ignored, mobile styles never appear, columns stay stuck in desktop mode, or the page still looks broken after the media query should have fired.

Why it happens

Media query bugs are usually caused by setup mistakes, invalid conditions, CSS conflicts, or layout assumptions that were never truly responsive to begin with.

What usually fixes it

Check the viewport tag, verify syntax, inspect rule order and specificity, then confirm the layout itself is actually flexible at that breakpoint.

Recommended baseline

Safe starting point

Start with the correct viewport tag, a clean media query, and a layout that actually has something flexible to change. 

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

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

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

.card {
  min-width: 0;
}

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

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

1. The viewport tag is missing

This is one of the most common answers to the question: why is my media query not working on mobile? Without the correct viewport tag, mobile browsers can pretend the page is desktop-sized and then scale it down visually.

That means your CSS may technically exist, but the browser is not rendering the page in a true mobile viewport.

Correct viewport tag

Required for real mobile behavior 
<meta name="viewport" content="width=device-width, initial-scale=1">

Broken syntax example

Tiny mistake, big confusion 
@media screen and(max-width: 768px) {
  .menu {
    display: none;
  }
}

2. Your media query syntax is invalid

Media query syntax is not forgiving. Missing spaces, malformed conditions, wrong punctuation, or invalid grouping can make the browser ignore the rule or interpret it differently than you expect.

The example above is broken because the spacing around and is wrong. Small errors like this waste hours because the CSS “looks almost right.”

Correct syntax

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

3. Your media query is being overridden

Sometimes the media query does work, but another rule with stronger specificity or later placement wins the cascade. This is one of the biggest reasons developers think the breakpoint is broken when the real problem is CSS order.

If your mobile rule appears first and the desktop rule appears later with equal or stronger specificity, the later rule can wipe out the mobile style.

Common override problem

Rule order conflict 
@media (max-width: 768px) {
  .card-title {
    font-size: 18px;
  }
}

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

Safer order

Desktop first example 
.card-title {
  font-size: 28px;
}

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

4. Your breakpoint logic is fighting your layout

A media query can be perfectly valid and still feel wrong if the logic behind it does not match the layout. Using the wrong breakpoint value, confusing min-width and max-width, or following no clear mobile-first or desktop-first logic creates confusion fast.

The rule may fire exactly when asked, but still fail to solve the real layout problem.

5. The bug is just a typo

Misspelling max-width, using the wrong class name, forgetting a closing brace, or writing the wrong selector is painfully common.

6. The media query works, but the layout is still rigid

One fixed-width container, oversized image, code block, or long string can make the whole page look non-responsive even when the media query actually fires.

The CSS file may not be updating

Browser cache, plugin cache, build issues, or stale compiled files can make you think your latest media query changes are not applying.

Fast practical rule

If your media query is not working, do not start by changing random breakpoint numbers. First confirm the viewport tag exists, then inspect syntax, then check whether another rule is winning the cascade.

Debug checklist

  • Confirm the page includes <meta name="viewport" content="width=device-width, initial-scale=1">.
  • Check the media query syntax carefully for spacing, braces, and valid conditions.
  • Inspect whether the selector inside the media query is being overridden by another rule later in the cascade.
  • Verify whether the breakpoint should use max-width or min-width.
  • Look for typos in property names, selectors, units, or class names.
  • Use DevTools to confirm whether the media query is firing and whether one child element is still breaking the layout.
  • Clear cache if you suspect the browser or platform is showing stale CSS.
Best first move Open DevTools, resize the viewport, and confirm whether the media query is actually activating before changing any code.
Most overlooked cause The viewport tag is missing, so the browser never behaves like a true mobile viewport in the first place.
Most frustrating cause The media query works, but another CSS rule later in the file silently overrides it.
Better mindset A media query is only part of responsive design. If the layout itself stays rigid, the breakpoint alone cannot save it.

Example of a layout that still feels broken

Even if the media query fires, a rigid container or overflowing child can keep the page feeling stuck in desktop mode. This is where many people wrongly conclude that the media query itself is dead.

Still rigid on mobile

Breakpoint fires, bug remains 
.wrapper {
  width: 1200px;
}

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

Final takeaway

Why is my media query not working? In most cases, the media query is not the villain. The real issue is usually missing viewport setup, invalid syntax, CSS order conflicts, incorrect breakpoint logic, a typo, or a rigid layout that still refuses to adapt.

Fix the real cause instead of guessing new breakpoint values, and responsive debugging becomes much faster and much less frustrating.

Want more fixes like this?

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

Responsive Fixes All Fixes

Fix position: sticky not working

by

Layout Fix

Fix position sticky not working.

If your sticky sidebar, header, filter bar, or table header refuses to stick, the problem is usually not sticky itself. It is usually a missing top value, a parent with overflow, or a layout context that prevents sticky behavior from ever activating.

Browse CSS Fixes See the Difference
  • Classic layout bug
  • Usually one hidden cause
  • Explained step-by-step

What the bug looks like

A sticky header scrolls away, a sidebar never sticks, or an element with position: sticky behaves exactly like relative.

Why it happens

Sticky depends on both the element and its surrounding layout. If the scroll container or parent rules are wrong, sticky never gets a chance to activate.

What usually fixes it

Add a proper offset, remove the wrong overflow from parents, and make sure the element actually has room to stick while the page scrolls.

Recommended base pattern

This is the clean starting point for most sticky headers, sidebars, and utility bars. 

.sidebar {
  position: sticky;
  top: 24px;
}

Common broken version

.sidebar {
  position: sticky;
}

Why this fails

Sticky needs a threshold. Without something like top: 0;, the browser has no clear point where the element should start sticking.

Rule of thumb: if sticky is not working, check the offset first. It is the fastest win.

Fast practical rule

If sticky is failing, do not start by changing ten layout properties. First ask three questions: does it have top? does a parent have overflow? is there enough scroll area for sticky to visibly activate?

The overflow trap

One of the biggest sticky killers is a parent element with overflow: hidden, overflow: auto, or overflow: scroll.

Sticky works relative to its scroll container. If the wrong parent becomes that container, sticky can appear broken or can stop at the wrong place.

Common sticky-breaking parent

.layout {
  overflow: hidden;
}

.sidebar {
  position: sticky;
  top: 24px;
}

Debug checklist

  • Make sure the sticky element has an offset such as top: 0; or top: 24px;.
  • Inspect all parent elements for overflow: hidden, auto, or scroll.
  • Check whether the sticky element is inside a container that is too short to allow visible sticky movement.
  • If the sticky element is in a flex or grid layout, inspect alignment and height behavior.
  • Test whether transforms or unusual wrappers are changing the layout context in unexpected ways.
Best first move Add top and inspect parent overflow before touching anything else.
Most overlooked cause Sticky often “fails” because the parent is not tall enough for the behavior to become visible during scroll.
Clean mindset Sticky is a layout relationship, not just a property. Debug the container chain, not only the element itself.

Sticky inside grid or flex layouts

Sticky can work inside grid and flex layouts, but the surrounding structure matters. If the column height is weird, the parent is stretched oddly, or overflow rules are fighting the scroll area, sticky may look unreliable.

This is why a sticky sidebar that works in one layout can fail in another with almost the same code.

Safer sidebar pattern

.layout {
  display: grid;
  grid-template-columns: 1fr 320px;
  gap: 24px;
}

.sidebar {
  position: sticky;
  top: 24px;
  align-self: start;
}

Helpful test

.sticky-test {
  position: sticky;
  top: 0;
  background: white;
}

Why this helps

A simplified sticky test helps separate “sticky is broken” from “my layout is breaking sticky.” If the basic version works, the real problem is probably in the parent structure.

Want more fixes like this?

Browse more layout debugging guides or jump to the full fix library.

Browse CSS Fixes All Fixes

Horizontal Scroll on Mobile? Fix the Hidden CSS Bug

by

Horizontal scroll on mobile usually means one hidden element is wider than the viewport. The page may look mostly fine, but one card, image, table, grid child, flex row, long string, or 100vw section can silently make the entire layout slide sideways.

Mobile Overflow Fix

Horizontal Scroll on Mobile? Fix the Hidden CSS Bug

Horizontal scroll on mobile is one of the most frustrating CSS bugs because the whole page feels broken even when only one element is guilty. This guide shows how to find the real overflowing element, why overflow-x:hidden can hide the symptom, and how to fix the actual width problem with safer CSS.

Browse Responsive Fixes Browse All Fixes
  • Mobile overflow debugging
  • 100vw and fixed width issues
  • Grid, flex, image and table fixes

What the bug looks like

The page moves left and right on mobile, a bottom scrollbar appears, or the right edge of the layout feels slightly cut off.

Why it happens

At least one element is demanding more width than the viewport can provide, so the document becomes wider than the screen.

What fixes it

Find the widest element, remove the rigid width, let children shrink, wrap long content, and only use clipping when it is intentional.

The simple rule behind horizontal scroll on mobile

Browsers do not create horizontal scroll randomly. If a page scrolls sideways, the document is wider than the viewport.

The hard part is that the guilty element is often not obvious. It may be a hidden row, a wide image, a table, a pre block, a grid item, a flex child, an iframe, or a wrapper using 100vw.

The fastest fix is not to hide the scrollbar first. The fastest fix is to identify which element is wider than the screen and repair that specific width behavior.

Error 1

A fixed-width element is wider than the phone

This is the most direct cause. A card, banner, image, button group, or wrapper has a fixed width that looks fine on desktop but becomes wider than the viewport on mobile.

Broken code

Fixed width 
.card {
  width: 420px;
}

Broken visual result

Card is wider than the viewport
420px card This card forces the document to become wider than the phone.

Correct code

Fluid width 
.card {
  width: 100%;
  max-width: 420px;
}

Fixed visual result

Card respects the viewport
Fluid card The card can shrink on mobile while keeping a max size on desktop.
Error 2

100vw creates extra width

width:100vw looks like the obvious way to make a full-width section, but it can cause horizontal overflow when the element also has padding, sits inside a wrapper, or interacts with scrollbar width.

Broken code

100vw trap 
.hero {
  width: 100vw;
  padding-inline: 24px;
}

Broken visual result

100vw plus padding can overflow
100vw section Width plus padding pushes beyond the safe layout area.

Correct code

Use container width 
.hero {
  width: 100%;
  padding-inline: 24px;
}

Fixed visual result

Section respects its parent
100% section The section now follows the parent width instead of forcing viewport math.
Error 3

Flex children refuse to wrap or shrink

A flex row can silently make the page wider when children have fixed widths, long text, or no wrapping behavior. This is common with buttons, cards, nav pills, and tag lists.

Broken code

No wrapping 
.button-row {
  display: flex;
  gap: 12px;
}

.button {
  min-width: 180px;
}

Broken visual result

Flex row is too wide
Button180px
Button180px
Button180px

Correct code

Wrap and shrink 
.button-row {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
}

.button {
  flex: 1 1 140px;
  min-width: 0;
}

Fixed visual result

Flex row wraps safely
ButtonFlexible
ButtonFlexible
ButtonFlexible
Error 4

CSS Grid columns demand too much width

A grid can create horizontal scroll when columns, gaps, or minmax() values require more space than mobile can provide. The fix is often reducing track pressure.

Broken code

Rigid grid 
.cards {
  display: grid;
  grid-template-columns: repeat(3, 150px);
  gap: 16px;
}

Broken visual result

Grid demands too much space
Card150px
Card150px
Card150px

Correct code

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

.card {
  min-width: 0;
}

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

Fixed visual result

Grid fits mobile width
Card oneFull width
Card twoFull width
Card threeFull width
Error 5

Long text, URLs, or code cannot break

A single unbroken string can create mobile horizontal scroll. This often happens with long URLs, file paths, code snippets, labels, product names, and generated IDs.

Broken code

No wrapping 
.title {
  white-space: nowrap;
}

Broken visual result

Text refuses to wrap
SuperLongUnbrokenURLOrCodeStringExample One line can push the page wider.

Correct code

Safe wrapping 
.title,
.url,
.code-label,
.long-text {
  overflow-wrap: anywhere;
}

Fixed visual result

Text can break safely
SuperLongUnbrokenURLOrCodeStringExample The string stays inside the card.
Error 6

A table or code block is too wide

Some content should scroll horizontally inside its own wrapper instead of forcing the entire page to scroll. Tables and code blocks are the classic examples.

Broken code

Page-level overflow 
table {
  width: 480px;
}

Broken visual result

Table widens the whole page
Name
Status
Action
Layout
Broken
Fix

Correct code

Local scroll 
.table-wrap {
  max-width: 100%;
  overflow-x: auto;
}

.table-wrap table {
  min-width: 480px;
}

Fixed visual result

Only the table wrapper scrolls
Name
Status
Action
Layout
Fixed
Safe

Fast practical rule

Horizontal scroll on mobile is almost always caused by one bad actor. Do not hide the scrollbar first. Find the widest element, then fix that element’s width, wrapping, or shrink behavior.

Recommended baseline

Mobile overflow foundation

This baseline does not replace real debugging, but it prevents many common mobile overflow problems. 

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

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

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

pre,
code {
  max-width: 100%;
  overflow-x: auto;
}

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

.long-text,
.url,
.label {
  overflow-wrap: anywhere;
}

.button-row {
  display: flex;
  flex-wrap: wrap;
}

Why this baseline helps

It keeps containers fluid width:min(100%, 1200px) prevents desktop widths from forcing mobile overflow.
It makes media behave Images, videos, and iframes stop forcing their natural width onto the page.
It lets children shrink min-width:0 is often the missing piece inside grid and flex layouts.
It handles ugly real content Long URLs, code labels, and generated strings can break safely instead of pushing the viewport.

Debug checklist

  • Open DevTools and test the exact mobile width where the page starts sliding sideways.
  • Look for any element extending beyond the right edge of the viewport.
  • Inspect cards, wrappers, images, tables, iframes, code blocks, nav rows, and button groups first.
  • Search for hard widths such as width:420px, min-width:500px, or width:100vw.
  • Check grid and flex children for missing min-width:0.
  • Check whether long text needs overflow-wrap:anywhere.
  • Wrap tables and code blocks in containers with overflow-x:auto when local scrolling is appropriate.
  • Use a temporary outline to reveal the element that is wider than the viewport.
  • Avoid using overflow-x:hidden until you know what is overflowing.
Best first move Slowly shrink the viewport in DevTools and watch which element crosses the right edge first.
Most common false fix Adding overflow-x:hidden to the body before identifying the actual overflowing element.
Most overlooked cause Grid and flex children often need min-width:0 before they can truly shrink.
Better mindset The page is usually not broken everywhere. One hidden element is usually poisoning the whole mobile layout.

Useful debug trick

Temporary outline

A temporary outline can reveal which element is wider than the viewport. Remove it after debugging. 

* {
  outline: 1px solid rgba(255, 0, 0, 0.18);
}

Why this trick works

Many overflow bugs are visually subtle. A single card may extend only a few pixels past the viewport, but that is enough to create sideways scroll.

The outline makes the invisible boundary visible. It is noisy, but it often finds the bug faster than guessing.

When overflow-x:hidden is acceptable

It can be acceptable when you intentionally want to clip decorative elements, animated shapes, or harmless visual effects that extend outside the viewport.

But it should not be your first fix for unknown horizontal scroll. If a real component is overflowing, hiding it can create hidden content, clipped menus, or accessibility issues.

Use clipping carefully

Last resort 
body {
  overflow-x: hidden; /* only after you know why */
}

.decorative-background {
  overflow: hidden; /* safer when intentionally scoped */
}

When CSS Grid is the real problem

If the horizontal scroll appears inside a card layout, the grid may be demanding too many columns, too much minimum width, or too much gap for mobile.

In that case, read Why is my CSS Grid breaking on mobile?.

When responsive design is the bigger problem

If several sections break at once, the issue may be a weak responsive foundation: fixed containers, missing viewport setup, rigid media, and bad breakpoint logic.

In that case, read Why is my responsive design not working?.

When container width is the real cause

Some pages scroll sideways because a wrapper or section uses a fixed width, wrong max-width, or width logic that ignores the viewport.

If the problem starts at the container level, read Fix container width problems.

When flex items refuse to shrink

A flex item can force horizontal scroll when it holds long content or fixed-width children and refuses to shrink inside the available space.

If that sounds familiar, read Fix flex item shrinking with fixed width.

Related fixes that can help

If horizontal scroll is one symptom of a bigger layout issue, these FrontFixer guides are the next places to check.

Fix CSS Grid breaking on mobile Use this when grid columns, gaps, or grid children are pushing the page wider than the viewport. Read this fix
Why is my responsive design not working? Use this when multiple parts of the page fail on mobile, not only one overflowing element. Read this fix
Fix container width problems Use this when the wrapper, section, or page container is wider than the screen. Read this fix

Final takeaway

Horizontal scroll on mobile is usually not a mysterious page-wide failure. It is usually one element demanding more width than the viewport can give.

Find the widest element first. Then fix the real cause: rigid widths, 100vw, unwrapped flex rows, aggressive grid tracks, long content, fixed media, tables, or code blocks.

Once the hidden overflowing element is fixed, the whole mobile layout usually feels stable again.

Need more mobile layout fixes?

Browse responsive fixes or jump back to the full FrontFixer library to keep debugging faster.

Responsive Fixes All Fixes

Fix HTML structure problems

by

HTML Fix

Fix HTML structure problems before they quietly break your layout.

If your layout feels random, CSS seems inconsistent, spacing breaks without a clear reason, or responsiveness keeps failing in weird ways, the real problem is often not your CSS at all. It is usually weak HTML structure underneath the page.

Browse HTML Fixes See the Difference
  • Often mistaken for a CSS issue
  • Breaks layouts silently
  • Common in real production work

Why HTML structure problems feel like CSS bugs

This kind of issue is frustrating because the visible symptom often appears in CSS, while the real cause lives in the markup. A section looks misaligned, a card refuses to behave, spacing feels inconsistent, or a responsive layout collapses too early. So the developer keeps changing CSS rules, but the bug never really leaves.

That is why HTML structure problems are so expensive in real projects. They make the wrong layer look guilty.

Common signs you should inspect the HTML first

Styles only work partially One part of the layout responds correctly while another part ignores the same logic.
Spacing feels inconsistent Margins, gaps, or alignment behave differently even when the CSS looks reasonable.
Responsive fixes feel weak You add breakpoints, but the mobile layout still feels structurally wrong.

Correct structure example

Cleaner markup 
<section class="container">
  <div class="card">
    <h2>Title</h2>
    <p>Content</p>
  </div>
</section>

Broken version

Weak structure 
<section>
  <h2>Title</h2>
</section>

<div class="card">
  <p>Content</p>
</div>

Why this fails

The layout is split into pieces that no longer belong together. The title and content are visually part of the same component, but the HTML does not reflect that relationship. Once the structure is broken like this, spacing, borders, card styles, background behavior, and responsive handling all become less predictable.

In simple terms: the CSS is not confused. The HTML is sending the wrong message.

Wrong parent-child logic

If elements are grouped visually but separated structurally, the layout often loses control over spacing and styling.

Weak component boundaries

A component should be wrapped as one logical unit. If it is split across unrelated containers, the CSS becomes harder to trust.

Harder long-term maintenance

Even if the broken version “works today,” it often creates more debugging pain the moment the design grows or the content changes.

Fast rule

If CSS feels broken, inspect the HTML first. A weak structure can make perfectly reasonable CSS look unreliable.

Debug checklist

  • Check parent-child relationships and confirm the markup groups elements the same way the design groups them.
  • Remove unnecessary wrapper divs that add complexity without adding structure.
  • Inspect the DOM in DevTools instead of assuming the markup matches the visual layout.
  • Confirm wrappers, containers, and inner layout layers actually exist where the CSS expects them.
  • Look for components split across unrelated parents, which often causes spacing and styling failures.

What better HTML improves

Cleaner layout control Stronger structure gives CSS a clearer foundation to work with.
More stable responsiveness Mobile fixes work better when the markup already reflects the real layout logic.
Easier maintenance Future edits become simpler when the HTML is readable, intentional, and less bloated.

Final takeaway

A lot of front-end bugs that look like CSS problems are actually structure problems wearing a CSS costume. That is why one of the smartest debugging habits you can build is checking the HTML before you keep stacking more layout rules on top of a weak foundation.

Clean markup makes styling easier, responsive behavior stronger, and future edits much less painful.

Fix structure first, then let CSS work properly.

Clean HTML makes layout behavior more predictable, reduces debugging time, and gives your CSS a much stronger foundation.

Browse HTML Fixes

Fix container width problems

by

Layout Fix

Fix container width problems before your layout starts feeling off.

If your page looks too wide, too narrow, visually unbalanced, or strangely misaligned between sections, the real problem is often not the content itself. It is usually the container system controlling the content.

Browse Fixes See the Difference
  • Very common layout issue
  • Often mistaken for spacing or typography
  • Can affect the whole page rhythm

Too wide

Text lines get long, cards spread too much, and the whole page starts feeling less intentional.

Too narrow

Desktop layouts feel boxed in and fail to use the available screen space properly.

Broken alignment

Sections, headings, grids, and CTA areas do not line up cleanly with each other.

Why container width problems matter more than people think

Container width controls the entire rhythm of the page. It affects how wide text can run, how grids breathe, how sections align, and whether the layout feels deliberate or sloppy.

That is why container bugs are often mistaken for typography problems, spacing problems, or visual design problems. But many times the issue starts much earlier: the page simply does not have one clean width system.

What usually causes them

Fixed widths A container that insists on one rigid width becomes fragile across screen sizes.
Missing max-width Without a limit, the page can stretch too far on wide displays.
Weak responsive padding The container may technically fit, but still feel cramped or inconsistent on smaller screens.

Recommended fix

Strong baseline pattern

This is a clean starting point for a container that stays flexible, centered, and much easier to trust across devices. 

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

Common mistake

Rigid width 
.container {
  width: 1200px;
}

Why this fails

A fixed width might look fine on one screen, but it becomes fragile the moment the viewport gets smaller. On mobile, it can create overflow. On tablets, it can feel awkward. On large screens, it may still not solve spacing rhythm correctly.

Simple rule: a container should adapt to available space instead of demanding one size forever.

One section uses a different width

The page may feel subtly broken because one hero, grid, or CTA area is not following the same width logic as the rest.

Padding is not part of the system

Without consistent horizontal padding, a container can technically fit while still feeling visually wrong.

Inner wrappers are fighting each other

Nested containers with different rules often create misalignment that gets blamed on layout or design.

Advanced pattern

More fluid padding

This version adds more responsive breathing room without losing control over the maximum layout width. 

.container {
  width: min(100%, 1200px);
  margin-inline: auto;
  padding-inline: clamp(16px, 4vw, 32px);
}

Fast practical rule

If the layout feels visually off across the whole page, check the container system before you start blaming the typography, spacing, or grid.

Real-world example

A landing page looked wrong on desktop. The typography seemed fine, the spacing seemed close, and nothing was obviously broken. But one section used a different width rule than the others, so the whole page felt slightly disconnected.

Once the sections shared the same container logic, the layout immediately felt more aligned, more premium, and more intentional — without rewriting the content.

Debug checklist

  • Check for fixed widths on main wrappers and section containers.
  • Confirm a max-width or equivalent width limit exists.
  • Add consistent padding-inline so content does not hug the viewport edges.
  • Make sure all major sections follow the same width system.
  • Inspect nested wrappers that may be introducing conflicting alignment rules.

What better container logic improves

Cleaner readability Text lines stop feeling too long or too cramped.
Stronger alignment Sections, cards, and content blocks line up more naturally.
Better responsive behavior The page adapts more gracefully instead of relying on patchwork fixes.

Final takeaway

Container width problems are often subtle, but they affect the entire feel of the page. When the width system is weak, layouts look less polished even if individual components are technically fine.

A stronger container system gives the whole interface more rhythm, more consistency, and much less visual friction.

Consistent containers create cleaner layouts.

Fix the container system, and the rest of the layout usually becomes much easier to trust.

Browse Fixes See the Difference

Fix responsive design not working

by

Responsive design usually stops working when one part of the layout refuses to shrink, wrap, stack, or respect the viewport. The fix is not always another media query. The real fix is finding the rigid element that is forcing desktop behavior on a smaller screen.

Responsive Design Fix

Why Is My Responsive Design Not Working?

Responsive design can look confusing because the page may work on desktop, partially change on mobile, and still feel broken. In most cases, the browser is not ignoring your CSS. One layout rule, one child element, one missing viewport tag, or one bad breakpoint is preventing the page from adapting correctly.

Browse Responsive Fixes Browse All Fixes
  • Mobile layout bugs
  • Viewport and breakpoint issues
  • Overflow and fixed-width debugging

What the bug looks like

The page scrolls sideways, cards stay in desktop columns, text runs outside its box, images overflow, or mobile styles seem to do nothing.

Why it happens

The layout contains a rigid assumption: a fixed width, a non-wrapping row, a wide child, a missing viewport setup, or a breakpoint that does not match the real failure point.

What fixes it

Start with the viewport, remove fixed widths, make media flexible, allow children to shrink, and adjust breakpoints only after you find what is actually breaking.

The simple rule behind responsive design bugs

Responsive design does not fail randomly. It fails when the layout is asked to fit a smaller screen but one part of the page refuses to adapt.

That stubborn part can be a container with width:1200px, a grid that never stacks, a flex row that never wraps, a long word that cannot break, an image without max-width:100%, or a media query that activates too late.

The fastest fix is usually not adding more CSS. The fastest fix is finding the one rule that is forcing the page to behave like desktop.

Error 1

The viewport meta tag is missing

This is the first thing to check. Without the correct viewport tag, a mobile browser may use a virtual desktop-sized viewport and scale the page down. That can make responsive CSS feel like it is broken even when your CSS rules exist.

Broken code

Missing viewport
<head>
  <title>My Page</title>
</head>

Broken visual result

Mobile behaves like desktop
Desktop layout squeezedThe browser is not using the screen width the way you expect.

Correct code

Viewport setup
<head>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My Page</title>
</head>

Fixed visual result

Screen width is respected
Mobile viewport worksThe layout can now respond to the real device width.
Error 2

A fixed-width container is forcing desktop layout

A container with a hard width is one of the most common reasons responsive design fails. If the container is wider than the screen, the page has no choice: it creates horizontal overflow.

Broken code

Rigid width
.container {
  width: 1200px;
  margin: 0 auto;
}

Broken visual result

Container is too wide
1200px containerThis box refuses to fit inside the smaller viewport.

Correct code

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

Fixed visual result

Container can shrink
Fluid containerThe container respects the screen while keeping a maximum desktop width.
Error 3

The grid does not stack on smaller screens

A desktop grid can look perfect at full width and then collapse badly on mobile. The problem is often that the grid keeps too many columns for too long.

Broken code

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

Broken visual result

Three columns are squeezed
CardToo narrow.
CardToo narrow.
CardToo narrow.

Correct code

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

.card {
  min-width: 0;
}

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

Fixed visual result

Cards stack cleanly
Card oneFull mobile width.
Card twoFull mobile width.
Card threeFull mobile width.
Error 4

Long content is creating hidden overflow

Sometimes the layout itself is mostly correct, but one piece of content is too stubborn. Long URLs, code snippets, product names, labels, buttons, and unbroken text can push the page wider than the viewport.

Broken code

No wrapping
.card-title {
  white-space: nowrap;
}

Broken visual result

Text refuses to wrap
SuperLongUnbrokenResponsiveLayoutBugExampleThe text pushes past the card.

Correct code

Safe wrapping
.card-title,
.long-text,
.url,
.label {
  overflow-wrap: anywhere;
}

Fixed visual result

Text can break safely
SuperLongUnbrokenResponsiveLayoutBugExampleThe content now stays inside the card.
Error 5

The breakpoint is chosen by habit, not by the layout

A breakpoint should be based on where the layout actually starts failing. If you copied a common breakpoint without testing the real content, your media query may activate too late.

Broken code

Too late
@media (max-width: 480px) {
  .layout {
    grid-template-columns: 1fr;
  }
}

Broken visual result

Breakpoint fires too late
Column 1cramped
Column 2cramped
Column 3cramped

Correct code

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

Fixed visual result

Layout stacks before breaking
Section 1enough space
Section 2enough space
Section 3enough space

Fast practical rule

If responsive design is not working, do not start by adding random breakpoints. First ask: what is the widest, most rigid, least flexible element on this page right now?

Recommended baseline

Responsive foundation

This is not a magic reset, but it gives most layouts a safer responsive foundation before you debug specific components.

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

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

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

.layout > * {
  min-width: 0;
}

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

pre,
code {
  max-width: 100%;
  overflow-x: auto;
}

.long-text,
.url,
.label {
  overflow-wrap: anywhere;
}

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

Why this baseline helps

It respects the real viewportThe viewport tag tells mobile browsers to use the device width properly.
It prevents rigid containerswidth:min(100%, 1200px) keeps the layout fluid while preserving a maximum desktop width.
It lets children shrinkmin-width:0 helps grid and flex children stop forcing overflow.
It handles real contentImages, videos, code blocks, URLs, and long labels are common sources of mobile layout bugs.

Debug checklist

  • Confirm the page includes <meta name="viewport" content="width=device-width, initial-scale=1">.
  • Inspect the page at the width where the layout first starts failing.
  • Look for fixed widths like width:1200px, min-width:900px, or wide components.
  • Check images, videos, iframes, tables, code blocks, buttons, and long text.
  • Use DevTools to find the element causing horizontal overflow.
  • Check whether grid or flex children need min-width:0.
  • Make sure columns stack before the layout becomes cramped.
  • Choose breakpoints based on where the layout breaks, not only on device names.
Best first moveOpen DevTools, shrink the viewport slowly, and find the exact width where the layout starts breaking.
Most common false fixAdding more media queries without finding the fixed-width or overflowing element.
Most overlooked causeA single child inside grid or flex that cannot shrink because it needs min-width:0 or safer wrapping.
Better mindsetResponsive debugging is less about memorizing breakpoints and more about removing rigid layout assumptions.

When overflow is the real problem

A page can look like the entire responsive system is broken when the real cause is just one element that is wider than the viewport.

This is common with tables, code blocks, long URLs, carousels, images, embeds, and button groups.

If your page scrolls sideways, read Fix overflow causing horizontal scroll.

When grid is the real problem

If only one grid section breaks on mobile, the issue may not be your whole responsive strategy. The problem may be the grid columns, child sizing, or lack of stacking.

In that case, read Fix CSS Grid breaking on mobile.

When HTML structure is the real problem

Sometimes the CSS looks complicated because the HTML structure is fighting against the layout. Extra wrappers, missing containers, weak grouping, or badly nested elements can make responsive behavior fragile.

If the layout keeps needing patches, read Fix HTML structure problems.

When flex items refuse to shrink

Flex layouts can also create responsive problems when an item keeps its content width and refuses to shrink inside the available space.

If that sounds familiar, read Fix flex item shrinking with fixed width.

Related fixes that can help

If your responsive design problem is part of a bigger layout issue, these FrontFixer guides are the next places to check.

Fix overflow causing horizontal scrollUse this when the page scrolls sideways or one hidden element is wider than the screen.Read this fix
Fix CSS Grid breaking on mobileUse this when cards, columns, or grid sections collapse badly on smaller screens.Read this fix
Fix HTML structure problemsUse this when CSS patches keep failing because the page structure is weak.Read this fix

Final takeaway

When responsive design is not working, the browser is usually exposing one rigid decision that desktop was hiding.

Start with the viewport. Then find fixed widths, overflowing children, non-wrapping content, grid or flex items that cannot shrink, and breakpoints that fire too late.

Once the stubborn element is fixed, the rest of the responsive layout usually becomes much easier to control.

Need more responsive fixes?

Browse the responsive cluster or jump back to the full FrontFixer library to keep debugging faster.

Responsive FixesAll Fixes

Fix z-index not working

by

z-index usually stops working when the element is not being compared in the layer system you think it is. The fix is rarely a bigger number. The real fix is checking positioning, stacking context, overflow clipping, and parent structure.

CSS Layering Fix

Why Is My z-index Not Working?

z-index can feel broken when a dropdown hides behind a section, a modal appears under a header, or a tooltip disappears even with a huge value. But the browser is usually following CSS stacking rules correctly. The problem is almost always the context around the element, not the number itself.

Browse CSS Fixes Browse All Fixes
  • CSS stacking context
  • Dropdown and modal bugs
  • Overflow and parent layer issues

What the bug looks like

A dropdown hides under another section, a modal appears behind a header, a tooltip gets cut off, or a sticky element refuses to sit above the page.

Why it happens

z-index only compares elements within stacking rules. A parent can trap the child inside a lower layer, so a huge number does not always win.

What fixes it

Add the right positioning, inspect parent stacking contexts, remove accidental clipping, and move important overlays to a safer layer when needed.

The simple rule behind z-index bugs

z-index is not one global ladder where the biggest number always wins. It works inside stacking contexts. A stacking context is like a small private layer system inside the page.

This means a child with z-index:9999 can still appear behind another element if the child is trapped inside a parent stacking context that sits lower than a different parent.

The fastest fix is usually not z-index:999999. The fastest fix is finding which parent is controlling the layer battle.

Error 1

The element has z-index but no positioning

This is the first thing to check. In many real layouts, z-index is expected to work on an element that has no positioning context. Add positioning intentionally before assuming the layer value is broken.

Broken code

No positioning 
.overlay {
  z-index: 9999;
}

Broken visual result

Number exists, layer does not win
Page section This section still appears above the overlay.
Overlay z-index alone is not a reliable setup.

Correct code

Positioned layer 
.overlay {
  position: relative;
  z-index: 20;
}

Fixed visual result

Element can now layer correctly
Page section This section is now behind the overlay.
Overlay Positioning gives the z-index a useful layer role.
Error 2

The dropdown is behind another section

Dropdowns often fail because the dropdown layer is lower than a nearby section, header, or card. The fix is not always a giant value. It is making the parent and dropdown layering intentional.

Broken code

Wrong layer order 
.nav {
  position: relative;
  z-index: 1;
}

.dropdown {
  position: absolute;
  z-index: 1;
}

.hero {
  position: relative;
  z-index: 5;
}

Broken visual result

Dropdown loses the layer battle
Navigation
Products
Pricing
Docs
Next section covers it

Correct code

Intentional layer 
.nav {
  position: relative;
  z-index: 30;
}

.dropdown {
  position: absolute;
  z-index: 40;
}

.hero {
  position: relative;
  z-index: 1;
}

Fixed visual result

Dropdown is above the content
Navigation
Next section stays behind
Products
Pricing
Docs
Error 3

A parent stacking context traps the child

This is the bug that makes developers angry. A child has z-index:9999, but it still appears behind another element because its parent is inside a lower stacking context.

Broken code

Trapped child 
.parent-a {
  position: relative;
  z-index: 1;
}

.child {
  position: absolute;
  z-index: 9999;
}

.parent-b {
  position: relative;
  z-index: 2;
}

Broken visual result

9999 is trapped inside parent A
Parent A z-index:1
Child z-index:9999
Parent B z-index:2

Correct code

Fix parent order 
.parent-a {
  position: relative;
  z-index: 5;
}

.child {
  position: absolute;
  z-index: 10;
}

.parent-b {
  position: relative;
  z-index: 2;
}

Fixed visual result

The parent layer now wins
Parent B z-index:2
Parent A z-index:5
Child z-index:10
Error 4

The element is clipped by overflow, not hidden by z-index

Sometimes the element is not behind anything. It is being cut off by a parent with overflow:hidden, overflow:auto, or another clipping behavior. That is a different bug.

Broken code

Clipped overlay 
.card {
  position: relative;
  overflow: hidden;
}

.tooltip {
  position: absolute;
  top: 100%;
  left: 0;
  z-index: 9999;
}

Broken visual result

Tooltip is cut off

Card with overflow hidden

The tooltip exists, but the parent clips it.

Tooltip z-index:9999, still clipped.

Correct code

Visible overlay 
.card {
  position: relative;
  overflow: visible;
}

.tooltip {
  position: absolute;
  top: calc(100% + 8px);
  left: 0;
  z-index: 20;
}

Fixed visual result

Tooltip can escape

Card with visible overflow

The overlay is allowed to appear outside.

Tooltip is visible now.
Error 5

A transform creates a new stacking context

A parent with transform can create a new stacking context. This often happens when people add transform:translateZ(0), animation helpers, GPU tricks, or subtle transform effects.

Broken code

Transform trap 
.wrapper {
  position: relative;
  transform: translateZ(0);
  z-index: 1;
}

.menu {
  position: absolute;
  z-index: 9999;
}

.panel {
  position: relative;
  z-index: 2;
}

Broken visual result

Transform created a layer trap
Transformed parent z-index:1
Menu z-index:9999
Neighbor layer z-index:2

Correct code

Avoid accidental context 
.wrapper {
  position: relative;
}

.menu {
  position: absolute;
  z-index: 30;
}

.panel {
  position: relative;
  z-index: 1;
}

Fixed visual result

The overlay layer is free
Wrapper no longer traps the menu
Neighbor stays behind
Menu layer works predictably

Fast practical rule

If z-index is not working, stop increasing the number and inspect the parent chain. The bug is usually positioning, stacking context, overflow clipping, or a parent with a property that created a new layer system.

Recommended baseline

Layering foundation

Use small, intentional z-index values and create a clear layer scale instead of throwing giant numbers at every bug. 

:root {
  --layer-base: 1;
  --layer-dropdown: 20;
  --layer-sticky: 30;
  --layer-modal: 40;
  --layer-toast: 50;
}

.nav {
  position: relative;
  z-index: var(--layer-sticky);
}

.dropdown {
  position: absolute;
  z-index: var(--layer-dropdown);
}

.modal {
  position: fixed;
  inset: 0;
  z-index: var(--layer-modal);
}

.toast {
  position: fixed;
  right: 16px;
  bottom: 16px;
  z-index: var(--layer-toast);
}

Why this baseline helps

It avoids number chaos You do not need 999999 everywhere when the layer system is planned.
It makes intent obvious A dropdown, modal, sticky bar, and toast each get a predictable role.
It exposes real bugs faster When the scale is clear, a broken layer usually points to parent context or overflow.
It is easier to maintain Future changes become safer because the site has a known layering order.

Debug checklist

  • Check whether the element has position:relative, absolute, fixed, or sticky.
  • Inspect the parent chain for transform, opacity, filter, perspective, isolation, contain, or will-change.
  • Check whether a parent has overflow:hidden, overflow:auto, or another clipping rule.
  • Confirm whether the issue is true layering or visual clipping.
  • Compare parent stacking contexts, not only child z-index values.
  • Avoid escalating from z-index:10 to 999999 without checking structure.
  • For modals and app-wide overlays, consider placing them near the end of the document or inside a dedicated layer root.
  • Use a simple layer scale for dropdowns, sticky elements, modals, and toasts.
Best first move Add positioning intentionally and inspect the parent chain before changing the z-index number again.
Most common false fix Using z-index:999999 while the element is trapped inside a lower parent context.
Most overlooked cause overflow:hidden makes many people think z-index is failing when the element is actually clipped.
Better mindset z-index is not a power contest. It is a relationship between positioned elements, parent contexts, and layer order.

When absolute positioning is the real problem

If an element is not only behind something but also appears in the wrong place, the issue may be absolute positioning. The element may be anchored to the wrong parent.

In that case, read Why is my absolute positioned element in the wrong place?.

When a dropdown is being cut off

If a menu or dropdown disappears at the edge of a card, section, slider, or container, the issue may be clipping rather than layer order.

In that case, read Why is my dropdown getting cut off?.

When fixed headers cover content

A fixed header can create another layer problem when it sits above content, anchors, modals, or dropdowns in unexpected ways.

If your sticky or fixed header is involved, read Why is my fixed header covering content?.

When overflow creates side effects

Overflow bugs can look like z-index bugs because they change what is visible on screen. But the solution is usually different.

If you are fighting overflow too, read Fix overflow causing horizontal scroll.

Related fixes that can help

If your z-index problem is part of a bigger CSS layout issue, these FrontFixer guides are the next places to check.

Why is my dropdown getting cut off? Use this when the element is being clipped by a parent instead of truly sitting behind something. Read this fix
Why is my absolute positioned element in the wrong place? Use this when the layer is also positioned relative to the wrong parent. Read this fix
Fix overflow causing horizontal scroll Use this when overflow is creating layout side effects that confuse the visual debugging. Read this fix

Final takeaway

When z-index is not working, the browser is usually not ignoring you. It is following stacking context rules that are easy to miss.

Start with positioning. Then inspect parent stacking contexts, overflow clipping, transformed wrappers, and the order of parent layers. Once the real layer system is clear, z-index becomes predictable again.

A clean parent structure beats a giant z-index number almost every time.

Need more CSS fixes?

Browse the CSS cluster or jump back to the full FrontFixer library to keep debugging faster.

CSS Fixes All Fixes

Fix Flexbox not centering (the right way)

by

Flexbox Fix

Fix Flexbox not centering elements the right way.

If your element refuses to center with Flexbox, Flexbox is usually not broken. The real problem is often simpler: you are centering on the wrong axis, using the wrong parent, or trying to center inside a container that has no usable space.

Browse CSS Fixes See the Difference
  • Very common bug
  • Usually an axis issue
  • Often fixed in minutes

What the bug looks like

The element stays stuck to one side, only centers in one direction, or looks like it is ignoring your alignment rules.

Why it happens

Flexbox alignment depends on axis direction, container space, and which element is actually the flex parent.

What usually fixes it

Check the correct axis first, then verify the parent, available height, and whether the child can actually appear centered visually.

The correct centering

Standard pattern 
.container {
  display: flex;
  justify-content: center; /* main axis */
  align-items: center;     /* cross axis */
  height: 300px;
}

Why this works

Flexbox has two axes, and each alignment property controls a different one.

  • Main axis → controlled by justify-content
  • Cross axis → controlled by align-items

Most centering bugs happen because these two get mixed up, or because the developer expects one property to do the work of both.

Common broken version

Axis mismatch 
.container {
  display: flex;
  align-items: center;
}

Why this fails

In the default row direction, align-items centers on the cross axis, which means vertical alignment. It does not horizontally center the child.

If your layout direction is horizontal, the main axis goes left to right. That means horizontal centering belongs to justify-content.

Wrong axis selected

This is the most common reason Flexbox “does not center.” The wrong property is being used for the direction that matters.

No usable vertical space

Even correct vertical centering looks broken if the parent has no height, because there is nothing to center inside.

Visual centering is not real centering

A full-width child can technically be centered, but still look left-aligned because the content inside the child is not centered.

Fast rule

If Flexbox is not centering, ask this first: am I using the correct axis? That one question solves a huge percentage of Flexbox alignment bugs.

When vertical centering fails

If align-items: center seems to do nothing, the parent often has no meaningful height. Flexbox cannot visually center something in a direction where there is almost no space.

  • Check whether the container has height or min-height
  • Make sure the element you are centering is inside the actual flex parent
  • Inspect whether the parent is collapsing to the height of its content

Fix example

Add usable space 
.container {
  display: flex;
  align-items: center;
  min-height: 200px;
}

Why the child can make centering look wrong

Sometimes the flex alignment is technically correct, but the child itself is full width or contains left-aligned content. That makes people think the item is not centered, when the real issue is inside the child, not the flex parent.

In those cases, you may need to center the child’s content separately or reduce the child width so the centering becomes visually obvious.

Common visual confusion

Child still looks left 
.container {
  display: flex;
  justify-content: center;
}

.child {
  width: 100%;
}

Debug checklist

Check the axis first In a row layout, horizontal centering usually means justify-content. Vertical centering usually means align-items.
Confirm the real flex parent The element you want centered must be a child of the container that actually has display: flex.
Check height for vertical centering If the container has no height, vertical centering will not look meaningful.
Inspect the child width A full-width child may create the illusion that centering is not happening.

Keep fixing layout bugs faster.

Explore more real-world CSS fixes or jump into the full FrontFixer library.

Browse CSS Fixes All Fixes

Fix CSS Grid Breaking on Mobile

by

CSS Grid usually breaks on mobile when the grid tracks, gaps, or child elements demand more width than the screen can provide. The fix is not always abandoning Grid. The real fix is making the grid tracks flexible, letting children shrink, and giving mobile a simpler layout when space gets tight.

CSS Grid Mobile Fix

Why Is My CSS Grid Breaking on Mobile?

CSS Grid can look perfect on desktop and then suddenly crush cards, create horizontal scroll, squeeze content, or refuse to stack on phones. Most of the time, Grid is not broken. The layout is simply asking small screens to carry desktop-sized columns, gaps, or children.

Browse CSS Fixes Browse All Fixes
  • Grid overflow bugs
  • Mobile track sizing
  • minmax and min-width fixes

What the bug looks like

Cards become tiny, text spills out, the page scrolls sideways, or the grid looks cramped and unstable on mobile.

Why it happens

The track sizing is too ambitious for the available width, or one child inside the grid refuses to shrink.

What fixes it

Use safer track sizing, reduce columns on mobile, control gaps, and add min-width:0 where grid children need to shrink.

The simple rule behind CSS Grid mobile bugs

A grid breaks on mobile when the total width requested by columns, gaps, padding, and child content is larger than the space available.

This can happen with obvious code like grid-template-columns: repeat(3, 300px), but it can also happen with elegant-looking rules like repeat(auto-fit, minmax(320px, 1fr)).

The fastest fix is usually to reduce the grid’s minimum demands and make the children flexible enough to fit.

Error 1

The grid keeps desktop columns on mobile

A desktop grid can look great at full width, but if it keeps three columns on a phone, the cards become cramped or overflow. Mobile usually needs a simpler column structure.

Broken code

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

Broken visual result

Three columns are squeezed
CardToo narrow.
CardToo narrow.
CardToo narrow.

Correct code

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

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

Fixed visual result

Cards stack cleanly
Card oneFull mobile width.
Card twoFull mobile width.
Card threeFull mobile width.
Error 2

The minmax() minimum is too large

auto-fit and minmax() are powerful, but they can still create mobile overflow if the minimum value is too ambitious for the real container width.

Broken code

Minimum too wide 
.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(320px, 1fr));
  gap: 24px;
}

Broken visual result

320px track is too demanding
320px minimumToo wide once padding is included.

Correct code

Safer minimum 
.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 220px), 1fr));
  gap: 20px;
}

Fixed visual result

Track can respect the container
Safe minimumThe track can fit the available width.
Error 3

The grid child refuses to shrink

Sometimes the columns are fine, but one child inside the grid refuses to shrink. This commonly happens with long text, nested flex items, code blocks, images, and buttons.

Broken code

Child is too wide 
.cards {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
}

.card-title {
  white-space: nowrap;
}

Broken visual result

Child forces the grid wider
VeryLongUnbrokenGridCardTitle Cannot shrink safely.

Correct code

Child can shrink 
.card {
  min-width: 0;
}

.card-title {
  overflow-wrap: anywhere;
}

Fixed visual result

Child stays inside the grid
VeryLongUnbrokenGridCardTitle The content can wrap and the card can shrink.
Error 4

Gap and padding push the grid over the limit

A grid may almost fit on mobile, but large gaps and container padding can reduce the usable width enough to create horizontal overflow.

Broken code

Spacing too large 
.wrapper {
  padding: 32px;
}

.cards {
  display: grid;
  grid-template-columns: repeat(2, 145px);
  gap: 28px;
}

Broken visual result

Spacing eats the mobile width
CardAlmost fits.
CardBut gap pushes it.

Correct code

Mobile spacing 
.wrapper {
  padding: 16px;
}

.cards {
  display: grid;
  grid-template-columns: 1fr;
  gap: 12px;
}

Fixed visual result

Spacing fits the screen
Card oneClean spacing.
Card twoNo overflow.
Error 5

Images and media are wider than the grid item

Images, videos, iframes, and embeds can break a grid when they do not respect the width of their card. The track may be correct, but the media inside it can still overflow.

Broken code

Media overflow 
.card img {
  width: 520px;
}

Broken visual result

Media is wider than the card
Fixed-width image area The image forces the card wider than the viewport.

Correct code

Fluid media 
.card img,
.card video,
.card iframe {
  max-width: 100%;
  height: auto;
  display: block;
}

Fixed visual result

Media respects the card
Fluid media area The media can scale down inside the grid item.

Fast practical rule

If CSS Grid is breaking on mobile, reduce the grid’s minimum demands first. Fewer columns, smaller gaps, flexible children, and min-width:0 solve more mobile Grid bugs than complicated track math.

Recommended baseline

Mobile-safe grid

This baseline gives the grid flexible tracks, allows children to shrink, keeps media fluid, and creates a simple mobile fallback. 

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

.card {
  min-width: 0;
}

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

.card-title,
.card-url,
.card-label {
  overflow-wrap: anywhere;
}

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

Why this baseline helps

It removes rigid track pressure minmax(0, 1fr) gives grid columns permission to shrink.
It protects against stubborn children min-width:0 helps grid items stop forcing overflow.
It makes media responsive Images, videos, and embeds stay inside their cards.
It gives mobile a clean fallback One column is often the safest and most readable mobile layout.

Debug checklist

  • Inspect the grid at the exact width where it first breaks.
  • Check whether the grid keeps too many columns on small screens.
  • Look for fixed track sizes like 300px, 320px, or aggressive minmax() values.
  • Add min-width:0 to grid items that contain long text, nested flex rows, images, or code blocks.
  • Check whether gaps and parent padding are making the usable width too small.
  • Make images, videos, iframes, and embeds fluid with max-width:100%.
  • Use overflow-wrap:anywhere for long strings, URLs, labels, and titles.
  • Switch to one column on mobile before trying more complex responsive grid formulas.
Best first move Temporarily set the grid to one column on mobile. If the bug disappears, your issue is track pressure or child overflow.
Most common false fix Rewriting the whole grid when one child simply needs min-width:0 or safer wrapping.
Most overlooked cause Big gaps and parent padding can make an otherwise reasonable grid overflow on a small screen.
Better mindset Mobile grids should be readable first and clever second. Predictable beats fancy when space is tight.

When overflow is the real problem

Sometimes Grid looks broken because one child is wider than the viewport. The grid is only revealing an overflow problem that already exists inside the content.

If the page scrolls sideways, read Fix overflow causing horizontal scroll.

When responsive design is the wider problem

If more than one section breaks on mobile, the issue may not be only Grid. The page may need a stronger responsive foundation.

In that case, read Why is my responsive design not working?.

When flex items inside the grid are the problem

A grid card can contain a flex row that refuses to shrink. That nested flex behavior can make the grid look guilty even when the grid track is fine.

If a nested flex child is involved, read Fix flex item shrinking with fixed width.

When the HTML structure is fighting the layout

Extra wrappers, missing containers, or weak grouping can make a grid harder to control across screen sizes.

If CSS patches keep failing, read Fix HTML structure problems.

Related fixes that can help

If your CSS Grid problem is part of a bigger responsive layout issue, these FrontFixer guides are the next places to check.

Fix overflow causing horizontal scroll Use this when a grid child or page section is wider than the viewport. Read this fix
Why is my responsive design not working? Use this when multiple sections fail on mobile, not only one grid. Read this fix
Fix flex item shrinking with fixed width Use this when a nested flex item inside a grid card causes overflow. Read this fix

Final takeaway

CSS Grid breaking on mobile is usually not a sign that Grid is unreliable. It is a sign that the layout is demanding more width than the screen can give.

Relax the track sizing. Let children shrink. Reduce gaps when needed. Make media fluid. Give mobile a simpler fallback before adding more clever formulas.

Once the grid’s minimum demands are realistic, CSS Grid becomes predictable again.

Need more CSS fixes?

Browse the CSS cluster or jump back to the full FrontFixer library to keep debugging faster.

CSS Fixes All Fixes