CSS Fixes

Why Is My CSS Not Updating After I Change It?

by

CSS not updating after you change it usually means the browser is still reading an old file, a different stylesheet, or a stronger CSS rule than the one you just edited.

CSS Debugging Fix

Why is my CSS not updating after I change it?

You change the CSS, save the file, refresh the page, and nothing happens. The button keeps the old color. The card still has the old spacing. The mobile layout still looks broken. In most real projects, the problem is not that CSS is ignoring you. The problem is usually cache, file order, specificity, the wrong stylesheet, minified assets, or a build process that has not generated the new file yet.

Browse CSS Fixes Browse All Fixes
  • CSS cache
  • Wrong stylesheet
  • Specificity conflicts
  • WordPress debugging

What the bug looks like

You change a color, margin, font size, layout rule, or mobile style, but the visible page keeps showing the old design.

Why it happens

The page is either loading old CSS, loading a different CSS file, or applying a stronger rule after your new rule.

What usually fixes it

Hard refresh, clear cache, confirm the loaded file in DevTools, inspect the rule, then fix specificity, order, or the build pipeline.

Error 1

The browser is still loading the cached stylesheet

This is the classic reason CSS changes do not show. You saved the file, but the browser already has an older version stored. So the code is changed on the server, while your screen still shows yesterday’s CSS.

Broken code

Old cached file 
<link rel="stylesheet" href="/assets/style.css">

/* You changed this today */
.hero-card {
  border-radius: 24px;
  background: white;
}

Broken visual result

Old CSS still visible
Old header style
Old card shape The page still looks like the previous version because the cached file is being used.
The CSS file was changed, but the browser did not request a fresh copy.

Correct code

Cache-busted file 
<link rel="stylesheet"
      href="/assets/style.css?v=2026-06-06">

/* New version now reaches the browser */
.hero-card {
  border-radius: 24px;
  background: white;
}

Fixed visual result

Fresh CSS loaded
Updated header style
New card shape The browser now loads the newer file, so the visual update finally appears.
Versioning the file URL forces the browser to request the updated stylesheet.
Error 2

A stronger selector overrides the CSS you changed

Sometimes the CSS is updating, but your rule is losing. In DevTools, the new property may appear crossed out because a more specific selector, inline style, or later rule is winning the cascade.

Broken code

Weak selector loses 
.button {
  background: #ff6a3d;
}

/* Later or stronger rule */
.header .button {
  background: #0f172a;
}

Broken visual result

New rule crossed out
.button background: #ff6a3d overridden
.header .button background: #0f172a wins
The file updated, but the rule you edited is not the rule controlling the final button style.

Correct code

Target the real selector 
.header .button {
  background: #ff6a3d;
}

.header .button:hover {
  background: #eb5628;
}

Fixed visual result

Correct rule wins
.header .button background: #ff6a3d active
.header .button:hover background: #eb5628 ready
The update works because the rule now matches the selector that actually controls the element.
Error 3

You edited a file the page is not loading

This one feels ridiculous until it happens. The CSS file you edited may not be the CSS file loaded by the page. WordPress themes, child themes, page builders, minified assets, and build tools can all create this confusion.

Broken code

Wrong file edited 
/* You edited this file */
themes/frontfixer/style.css

.card {
  padding: 28px;
}

/* But the page actually loads */
uploads/cache/minified-style.css

Broken visual result

Wrong source file
themes/frontfixer/style.css edited
uploads/cache/minified-style.css loaded
Your code changed, but not in the file that the browser is currently using.

Correct code

Confirm loaded source 
/* In DevTools, check the rule source */
.card {
  padding: 28px;
}

/* Then edit the real source or purge/rebuild */
Loaded file:
style.css?ver=2026-06-06

Fixed visual result

Right file confirmed
style.css?ver=2026-06-06 loaded
.card padding: 28px active
DevTools tells you the exact stylesheet and line where the winning rule is coming from.
Error 4

WordPress cache or optimization is serving old CSS

In WordPress, your CSS may be correct but still not visible because an optimization plugin, server cache, CDN cache, or minified file is serving an older generated version. This is common after editing Custom CSS, theme files, or page-level HTML/CSS.

Broken setup

Old optimized CSS 
Original CSS changed:
.card {
  border-radius: 24px;
}

/* But the front-end still loads */
combined.min.css
cached by plugin/CDN/server

Broken visual result

Optimized file is stale
Cached version
Old minified CSS The page is still using a generated file that has not been refreshed.
Clearing only the browser cache may not be enough if the server or plugin is serving old CSS.

Correct workflow

Purge and rebuild 
After editing CSS:

1. Save the post/theme/CSS file
2. Purge plugin cache
3. Purge server/CDN cache if used
4. Regenerate/minify CSS if needed
5. Hard refresh the browser

Fixed visual result

Fresh optimized CSS
Updated version
New generated file The optimized CSS has been rebuilt, so the live page finally matches your edit.
For WordPress sites, always think in layers: browser cache, plugin cache, server cache, CDN cache.
Premium pattern

A production-minded CSS update workflow

The stronger fix is not just refreshing harder. A reliable workflow makes CSS updates predictable: version your stylesheet, inspect the winning rule, avoid random specificity wars, and use a clear cache purge routine after important changes.

Premium workflow

Predictable updates 
<link rel="stylesheet"
      href="/assets/style.css?v=2026-06-06">

/* Keep selectors intentional */
.ffx-card {
  padding: clamp(18px, 3vw, 28px);
  border-radius: 24px;
}

/* Avoid random emergency overrides */
.ffx-card.is-featured {
  border-color: #ffd2c2;
  box-shadow: 0 18px 38px rgba(255,106,61,.12);
}

/* After deploying:
   hard refresh, inspect source,
   purge cache, then request indexing
   for important updated pages. */

Premium visual result

Clean update path
Production-ready CSS
Predictable visual update The stylesheet is versioned, the selector is intentional, and the cache workflow is clear.
The premium version does not rely on panic-refreshing. It makes the CSS pipeline easier to trust.

Fast practical rule

If CSS is not updating, do not immediately add !important. First check whether the browser is loading the new file at all. Then inspect the exact rule in DevTools. If the file is old, fix cache. If the rule is crossed out, fix specificity or order.

Debug checklist

  • Hard refresh the page with the browser cache bypassed.
  • Open DevTools and confirm the stylesheet URL actually changed or loaded fresh.
  • Inspect the element and check whether your rule is active or crossed out.
  • Confirm you edited the stylesheet that the page is really loading.
  • Check whether a later rule overrides your new rule.
  • Check selector specificity before using !important.
  • Clear WordPress plugin cache, server cache, CDN cache, and minified CSS when relevant.
  • If your project uses a build process, rebuild the compiled CSS file.
  • Test in an incognito window or another browser to separate browser cache from server cache.
Best first move Inspect the element in DevTools and check whether your new rule appears at all.
Most common cause Browser, plugin, CDN, or server cache is still serving an older CSS file.
Most misleading cause The CSS changed, but another selector is stronger, so the visual result stays the same.
Better mindset CSS debugging is not guessing. It is proving which file loaded and which rule won.

Related fixes that can help

If your CSS change appears saved but the layout still looks wrong, the real cause may be a media query, responsive structure, overflow, or selector problem.

Why is my media query not working? If mobile CSS changes do not appear or your breakpoint seems ignored. Read this fix
Why is my responsive design not working? If the CSS updates, but the page still behaves like a desktop layout. Read this fix
Horizontal scroll on mobile? If your CSS change creates or fails to fix sideways scrolling on small screens. Read this fix

Final takeaway

CSS not updating is usually not a mystery. The page is either loading an old stylesheet, loading a different stylesheet, or applying a different rule than the one you edited. Once you separate those three possibilities, the bug becomes much easier to fix.

Start with DevTools. Confirm the file. Confirm the selector. Confirm the winning rule. Then clear or rebuild the cache only where needed. That is faster than stacking random overrides until the stylesheet becomes harder to maintain.

Want more fixes like this?

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

CSS Fixes All Fixes

Why Is My Absolute Positioned Element in the Wrong Place?

by

An absolute positioned element usually appears in the wrong place when it is not anchored to the parent you think it is, because CSS positions it relative to the nearest positioned ancestor.

CSS Positioning Fix

Why Is My Absolute Positioned Element in the Wrong Place?

An absolute positioned element can look confusing because it feels like top, right, bottom, and left should position the element inside the visible card, button, image, or container. But CSS does not position an absolute element relative to the nearest visual box. It positions it relative to the nearest ancestor that has a positioning context, usually an element with position:relative, absolute, fixed, or sticky.

Browse All Fixes Explore CSS Fixes
  • Absolute positioning
  • Wrong parent issue
  • Visual CSS debugging

What the bug looks like

A badge, tooltip, icon, modal, label, menu, or decorative element appears far away from the card or container it belongs to.

Why it happens

The absolute element is using the wrong containing block, usually because the intended parent does not create a positioning context.

What fixes it

Add position:relative to the correct parent, use clear inset values, and avoid using absolute positioning for normal layout flow.

The simple rule behind absolute positioning

The most important rule is this: an absolute positioned element is positioned relative to its nearest positioned ancestor. A “positioned ancestor” means an ancestor with a position value other than static.

If no suitable positioned ancestor exists, the element may use a much higher ancestor, often the page or initial containing block. That is why a small badge meant for a product card can suddenly appear near the page corner instead of inside the card.

Error 1

The parent is missing position:relative

This is the classic absolute positioning bug. You place a badge inside a card and expect it to sit in the top-right corner of that card. But the card does not have position:relative, so the badge looks for another ancestor to use as its positioning reference.

Broken code

Missing parent 
.card { padding: 24px; border: 1px solid #ddd; } .badge { position: absolute; top: 12px; right: 12px; }

Broken visual result

Badge escapes the card
NEW

Product card

The badge should belong to this card, but the card did not create a positioning context.

The badge is positioned absolutely, but not relative to the card.

Correct code

Correct anchor 
.card { position: relative; padding: 24px; border: 1px solid #ddd; } .badge { position: absolute; top: 12px; right: 12px; }

Fixed visual result

Badge is anchored
NEW

Product card

The card now creates the positioning context, so the badge knows where it belongs.

The badge is now positioned relative to the card, not the page.
Error 2

Trying to center with only top:50% and left:50%

Another common absolute positioning mistake is trying to center an element with only top:50% and left:50%. That moves the element’s top-left corner to the center of the parent. It does not center the whole element.

Broken code

Half centered 
.parent { position: relative; } .modal { position: absolute; top: 50%; left: 50%; }

Broken visual result

Top-left corner is centered
Modal The top-left corner starts at the center, so the whole box is pushed down and right.
The center lines hit the modal’s corner, not its center.

Correct code

True center 
.parent { position: relative; } .modal { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); }

Fixed visual result

Whole element is centered
Modal The transform pulls the element back by half of its own size.
The center lines now pass through the center of the modal.
Error 3

Using absolute positioning for normal layout spacing

Absolute positioning removes the element from normal document flow. That means the parent does not reserve space for it. This is useful for badges, icons, overlays, and decorative elements, but dangerous for normal content that should affect the layout.

Broken code

Removed from flow 
.card { padding: 20px; } .actions { position: absolute; right: 14px; top: 14px; }

Broken visual result

No space is reserved
Actions Card title

The button floats over the content because absolute elements do not reserve layout space.

Next section starts without caring about the absolute child above.
Absolute positioning is not a replacement for layout structure.

Correct code

Reserve space 
.card { position: relative; padding: 20px; padding-right: 120px; } .actions { position: absolute; right: 14px; top: 14px; }

Fixed visual result

Space is planned
Actions Card title

The card reserves room for the absolute button, so content does not crash into it.

Next section now follows a more predictable layout.
If the element is essential content, consider Flexbox or Grid instead.
Error 4

The absolute element is clipped by overflow:hidden

Sometimes the absolute positioned element is technically in the right place, but you cannot see all of it. The parent may be clipping anything that goes outside its box with overflow:hidden. This is common with tooltips, badges, dropdowns, and popovers.

Broken code

Clipped child 
.card { position: relative; overflow: hidden; } .tooltip { position: absolute; top: 100%; left: 0; }

Broken visual result

Tooltip is cut off
Hover target
Tooltip content is positioned correctly, but the parent clips it.
This is related to dropdown clipping and overflow bugs.

Correct code

Visible overlay 
.card { position: relative; overflow: visible; } .tooltip { position: absolute; top: calc(100% + 8px); left: 0; }

Fixed visual result

Tooltip is visible
Hover target
Tooltip content can now appear outside the parent box.
If clipping is required for the card design, move the overlay outside the clipped parent.

Fast practical rule

If an absolute positioned element is in the wrong place, first check the parent. The fix is often not a bigger top, left, or z-index value. The fix is usually adding position:relative to the correct parent so the absolute child has the right reference point.

When should you use absolute positioning?

Absolute positioning is best for UI details that should sit on top of a layout, not for building the main layout itself. Use it for badges, icons, decorative marks, small overlays, close buttons, tooltips, labels, and controlled UI pieces.

Do not use absolute positioning just to push normal content into place. If the content should affect the size of the parent, use Flexbox, Grid, margin, padding, or normal document flow instead.

Good absolute pattern

Reusable 
.component { position: relative; } .component__badge { position: absolute; top: 12px; right: 12px; }

This pattern is simple and predictable: the component creates the positioning context, and the badge uses that component as its reference.

Debug checklist

  • Check whether the intended parent has position:relative.
  • Inspect which ancestor the absolute element is actually using as its containing block.
  • Remember that top:50% and left:50% center the corner, not the whole element.
  • Use transform:translate(-50%,-50%) when centering an absolute element with 50% offsets.
  • Do not use absolute positioning for normal content that should reserve layout space.
  • Check whether overflow:hidden is clipping the element.
  • Check whether the element is hidden behind something else because of stacking context or z-index.
  • Use Flexbox or Grid when the element is part of the main layout.
Best first move Add position:relative to the parent that should control the absolute child.
Most common false fix Keep increasing top, left, or z-index without fixing the parent context.
Most overlooked cause The absolute element is positioned correctly, but a parent with overflow:hidden is clipping it.
Better mindset Absolute positioning is for controlled overlays, not for forcing the whole layout into place.

Related fixes that can help

If your absolute positioned element is part of a bigger layout, overlay, or clipping problem, these FrontFixer guides are the next places to check.

Fix z-index not working If the absolute element is in the right place but appears behind another element. Read this fix
Why is my dropdown getting cut off? If the problem is a menu, tooltip, popover, or overlay being clipped by a parent. Read this fix
Fix HTML structure problems If weak markup is making the positioning logic harder to control. Read this fix

Final takeaway

An absolute positioned element appears in the wrong place when it is anchored to the wrong reference point. The most common reason is simple: the parent you expected to control the element does not have position:relative.

Start by setting a clear positioning context on the correct parent. Then check your inset values, centering logic, normal flow spacing, overflow clipping, and stacking context. Once the parent-child relationship is clear, absolute positioning becomes predictable instead of mysterious.

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 Text Overflowing Outside the Box in CSS?

by

Text overflowing outside the box in CSS usually happens when long words, URLs, code strings, button labels, flex items, or grid columns cannot wrap or shrink safely inside their container.

CSS Overflow Fix

Why Is My Text Overflowing Outside the Box in CSS?

Text overflowing outside the box in CSS is one of those bugs that looks small until it breaks the whole layout. A single long URL, username, token, product title, button label, table value, or code string can push past a card, force horizontal scroll on mobile, stretch a grid column, or make a clean interface look broken. The fix is not simply “make the box wider.” The real fix is understanding how wrapping, minimum width, Flexbox, Grid, and overflow rules work together.

Browse All Fixes Explore CSS Fixes
  • Long URLs
  • Flexbox min-width
  • Grid overflow
  • Mobile horizontal scroll

What the bug looks like

Text sticks out of a box, the page becomes wider than the screen, a card refuses to shrink, or a button/table column pushes the layout sideways.

Why it happens

The browser cannot find a safe place to break the content, or the layout parent is not allowed to shrink the child to the available width.

What usually fixes it

Add safe wrapping, remove accidental nowrap, use min-width:0 in flex/grid children, and use local scrolling for tables or code blocks.

The core rule: text can only wrap where the browser is allowed to break it

Normal sentences wrap easily because they have spaces. A browser can move words to the next line without changing the text. But long unbroken strings are different. A URL, a package name, a long email address, an API token, or a generated product ID may not have a comfortable break point.

When the browser cannot break the string, the string becomes wider than the box. That one piece of content can then pressure the parent card, the flex row, the grid column, and sometimes the entire viewport. This is why text overflow often appears together with horizontal scroll on mobile, flex item shrinking problems, and CSS Grid breaking on mobile.

Error 1

The text has no safe wrapping rule

The most common version of this bug is a card or content block that looks fine with normal text, then breaks as soon as a long URL, code string, or unbroken word appears.

Broken code

No wrap protection 
.card {
  max-width: 320px;
  padding: 24px;
  border: 1px solid #ddd;
}

.card p {
  font-size: 16px;
}

Broken visual result

Text escapes
Comment card VeryLongUnbreakableTextThatPushesOutsideTheCardAndBreaksTheLayout
The content keeps going sideways →

The box has a width, but the long text has no safe wrapping instruction.

Correct code

Safe wrapping 
.card {
  max-width: 320px;
  padding: 24px;
  border: 1px solid #ddd;
}

.card p {
  overflow-wrap: anywhere;
}

Fixed visual result

Text stays inside
Comment card VeryLongUnbreakableTextThatCanNowBreakBeforeItDestroysTheLayout

The browser is now allowed to break the long string before it overflows the card.

Error 2

white-space:nowrap is blocking the wrap

white-space:nowrap is useful for short labels, menu items, and compact UI, but it becomes dangerous when the text can be long, translated, dynamic, or user-generated.

Broken code

Forced one line 
.button {
  max-width: 100%;
  padding: 12px 18px;
  white-space: nowrap;
}

Why this breaks

The button is told to stay on one line. If the label becomes longer than the available width, the button may stretch past its parent or overflow on mobile.

Correct code

Allow wrapping 
.button {
  max-width: 100%;
  padding: 12px 18px;
  white-space: normal;
  overflow-wrap: anywhere;
}

When to use this

Use this for dynamic buttons, translated labels, long CTAs, admin panels, dashboards, and any component where text length is not fully controlled.

Error 3

The flex child needs min-width:0

This is the part many developers miss. You can add overflow-wrap:anywhere to the text, but the layout may still overflow if the flex child refuses to shrink. Flex items have an automatic minimum size that can protect their content too aggressively.

Broken code

Flex trap 
.row {
  display: flex;
  gap: 16px;
}

.content {
  flex: 1;
}

.content p {
  overflow-wrap: anywhere;
}

Broken visual result

Flex child resists
Message LongUnbrokenMessageTextCanStillPressureTheFlexRow

The text rule is there, but the flex child may still need permission to shrink.

Correct code

Shrink allowed 
.row {
  display: flex;
  gap: 16px;
}

.content {
  flex: 1;
  min-width: 0;
}

.content p {
  overflow-wrap: anywhere;
}

Fixed visual result

Flex child shrinks
Message LongUnbrokenMessageTextCanNowWrapInsideTheAvailableSpace

min-width:0 lets the flex item shrink, and wrapping keeps the text inside.

Error 4

Grid columns are using plain 1fr

CSS Grid can also overflow when content refuses to shrink. A common fix is replacing plain 1fr tracks with minmax(0,1fr), then making sure grid children are allowed to shrink.

Broken code

Content pressure 
.grid {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 24px;
}

.card p {
  overflow-wrap: anywhere;
}

Broken visual result

Grid gets pressured
LongGridTextCanPressureTheColumn
Normal text

The grid track may still be influenced by long content.

Correct code

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

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

.card p {
  overflow-wrap: anywhere;
}

Fixed visual result

Grid respects width
LongGridTextCanNowWrapInsideTheColumn
Normal text

minmax(0,1fr) helps the flexible track stay inside the available layout width.

Error 5

You are trying to force tables or code blocks to wrap when they should scroll locally

Not every overflow should be wrapped. Tables, code blocks, terminal output, and comparison grids often need their own horizontal scroll area. The mistake is letting them make the entire page scroll sideways.

Broken code

Page-level overflow 
.content table {
  width: 100%;
}

pre {
  white-space: pre;
}

Correct code

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

pre {
  overflow-x: auto;
}
Content type Best behavior Why
Normal paragraphs overflow-wrap:anywhere Text should remain readable inside the card or column.
Long URLs overflow-wrap:anywhere URLs can behave like one huge word and break mobile layouts.
Tables overflow-x:auto on wrapper Trying to squeeze columns can destroy readability.
Code blocks Local horizontal scroll Code indentation and line structure should often be preserved.
The goal is not to eliminate every horizontal scroll. The goal is to stop one element from making the entire page scroll sideways.

Fast practical rule

If text is overflowing outside the box, do not start by hiding it with overflow:hidden. First ask: can this content wrap? Is white-space:nowrap blocking wrapping? Is the parent a flex or grid item that needs min-width:0? Should this content wrap, or should it scroll inside its own local wrapper?

overflow-wrap:anywhere vs word-break:break-all

A lot of developers reach for word-break:break-all when text overflows. It works, but it can be too aggressive. It may break normal words in ugly places even when better wrapping options exist.

For most real interfaces, start with overflow-wrap:anywhere. It gives the browser permission to break long content when needed, without making every normal sentence look chopped up.

Better first choice

Cleaner breaks 
/* Usually the better first fix */
.text {
  overflow-wrap: anywhere;
}

/* More aggressive */
.text {
  word-break: break-all;
}

Reusable safe content utility

Production pattern 
.safe-content {
  min-width: 0;
  overflow-wrap: anywhere;
}

.card,
.comment,
.message,
.product-title,
.table-cell,
.sidebar,
.button {
  overflow-wrap: anywhere;
}

Where this pattern helps most

Use a safe wrapping pattern anywhere content can be unpredictable: user comments, support tickets, dashboards, admin tables, documentation pages, pricing cards, profile pages, product grids, chat messages, and mobile navigation.

It is especially helpful when your content comes from users, APIs, CMS fields, translations, or generated strings that you cannot fully control.

Debug checklist

  • Find the exact text causing the overflow: URL, email, long word, token, slug, file path, button label, or code string.
  • Add overflow-wrap:anywhere to the text or content wrapper.
  • Remove accidental white-space:nowrap when wrapping should be allowed.
  • If the text is inside Flexbox, add min-width:0 to the flexible child.
  • If the text is inside CSS Grid, use minmax(0,1fr) for flexible tracks.
  • Add min-width:0 to grid children when long content is inside them.
  • Use local overflow-x:auto wrappers for tables and code blocks instead of making the whole page scroll.
  • Do not hide real content with overflow:hidden unless clipping is actually the design goal.
  • Test on a narrow mobile viewport, not only a wide desktop browser.
Best first move Add overflow-wrap:anywhere to the text area that can receive long content.
Most common false fix Making the container wider instead of allowing the content to wrap.
Most overlooked cause The parent flex or grid item may need min-width:0.
Senior-level mindset Text overflow is not just a typography bug. It is often a content, wrapping, and layout-sizing bug at the same time.

Related fixes that can help

If text overflowing outside the box is part of a larger layout problem, these FrontFixer guides are the next places to check.

Horizontal Scroll on Mobile? Fix the Hidden CSS Bug If a long text string is making the whole mobile page scroll sideways. Read this fix
Why Is My Flex Item Shrinking Even With a Fixed Width? If Flexbox sizing is compressing or pressuring a layout in ways that feel confusing. Read this fix
Fix CSS Grid Breaking on Mobile If the overflowing text is inside a grid column or responsive card layout. Read this fix

Final takeaway

Text overflowing outside the box in CSS usually means the browser is missing one of three things: permission to break long content, permission for the parent layout item to shrink, or a local scroll wrapper for content that should not be forced into a tiny column.

Start with overflow-wrap:anywhere. Then remove accidental white-space:nowrap. If the text is inside Flexbox or Grid, add min-width:0 to the right child and use safer grid tracks like minmax(0,1fr). Once wrapping and layout sizing work together, the text stays inside the box instead of breaking the page.

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 Flex Item Shrinking Even With a Fixed Width?

by

Flex item shrinking problems usually happen when Flexbox is allowed to compress an item, even when that item has a fixed width in your CSS. In most cases, the real fix is not a bigger width — it is controlling flex-shrink, flex-basis, and the neighboring content.

Flexbox CSS Fix

Why is my flex item shrinking even with a fixed width?

A flex item shrinking even after you set width:300px feels like the browser is ignoring your CSS. But in Flexbox, width is not always a locked promise. It can become the item’s preferred starting size, while flex-shrink:1 still gives the browser permission to compress it when the row runs out of space.

This usually affects fixed sidebars, image columns, avatar blocks, pricing cards, navigation items, media objects, and dashboard panels. The layout looks fine on a wide screen, then suddenly the “fixed” part gets squeezed, crushed, or narrower than the width you wrote in CSS.

Browse All Fixes Explore CSS Fixes
  • Flexbox sizing
  • Fixed sidebar bugs
  • flex-shrink
  • min-width:0

What the bug looks like

The sidebar, thumbnail, avatar area, or fixed card becomes narrower than expected even though DevTools shows a width in your CSS.

Why it happens

Flexbox is trying to fit all children into one row. If the row has less space than it needs, shrinkable flex items can be compressed.

What usually fixes it

Disable shrinking on the fixed item, define a clear flex basis, allow the content column to shrink, and stack the layout on small screens.

The simple rule behind this Flexbox bug

Flexbox does not only read width. It runs a sizing negotiation. Each flex item starts with a base size, then the browser checks whether the container has extra space or not enough space. If there is extra space, flex-grow can distribute it. If there is not enough space, flex-shrink can remove space from items.

That is why width:300px can still shrink. The width says “start around 300px.” The default flex-shrink:1 says “but you may reduce me if the row is too tight.” Once you understand that difference, the bug stops feeling random.

Error 1

Relying on width alone

This is the most common trap. You give the item a fixed width, but you never tell Flexbox that the item is forbidden from shrinking. So the browser still has permission to compress it.

Broken code

Width trap 
.layout {
  display: flex;
  gap: 24px;
}

.sidebar {
  width: 300px;
}

.content {
  flex: 1;
}

Broken visual result

Fixed width gets crushed
Sidebar width: 300px
Content wants space

The width exists, but the item is still shrinkable, so Flexbox can squeeze it when the row becomes tight.

Correct code

No shrinking 
.layout {
  display: flex;
  gap: 24px;
}

.sidebar {
  width: 300px;
  flex-shrink: 0;
}

.content {
  flex: 1;
  min-width: 0;
}

Fixed visual result

The fixed item is protected
Protected sidebar
Content adapts

flex-shrink:0 tells the browser not to steal width from the sidebar.

Error 2

Not using flex-basis for the protected size

In many production layouts, the cleaner solution is not just width plus flex-shrink:0. It is using the Flexbox shorthand to define grow, shrink, and basis in one predictable rule.

Fragile code

Mixed signals 
.media {
  width: 220px;
}

.text {
  flex: 1;
}

Why this is weaker

It can work, but the fixed item’s size is not fully described in flex terms. The browser still has to combine width with default flex behavior.

Stronger code

Production pattern 
.media {
  flex: 0 0 220px;
}

.text {
  flex: 1 1 auto;
  min-width: 0;
}

Why this is stronger

flex:0 0 220px says: do not grow, do not shrink, and use 220px as the flex basis. That is clearer than hoping width wins.

Error 3

Forgetting min-width:0 on the flexible content

Sometimes the fixed item is innocent. The content next to it refuses to shrink because it contains long text, an unbreakable URL, a code string, a wide image, or default minimum sizing. This creates pressure that makes the fixed area look broken.

Broken code

Content pressure 
.sidebar {
  flex: 0 0 300px;
}

.content {
  flex: 1;
}

Why this can still fail

The content column may have a default minimum size based on its content. If it refuses to shrink, the whole row can overflow or create unexpected pressure.

Correct code

Shrink safely 
.sidebar {
  flex: 0 0 300px;
}

.content {
  flex: 1 1 auto;
  min-width: 0;
}

.content p,
.content a,
.content code {
  overflow-wrap: anywhere;
}

Why this works

min-width:0 lets the flexible content become smaller than its natural content width. overflow-wrap:anywhere helps long text break instead of forcing the layout wider.

Error 4

Protecting the fixed item on screens that are too small

flex-shrink:0 is not magic. It protects the item, but if the screen is too narrow, protecting a 300px sidebar beside a content column can create horizontal scroll. On mobile, the layout may need to stack.

Broken mobile behavior

Too rigid 
.layout {
  display: flex;
}

.sidebar {
  flex: 0 0 300px;
}

.content {
  flex: 1 1 auto;
}

Broken visual result

Mobile crush
IMG

A protected desktop layout can become too wide for mobile if you never change the layout direction.

Correct mobile behavior

Stack when needed 
.layout {
  display: flex;
  gap: 24px;
}

.sidebar {
  flex: 0 0 300px;
}

.content {
  flex: 1 1 auto;
  min-width: 0;
}

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

  .sidebar {
    flex-basis: auto;
    width: 100%;
  }
}

Fixed visual result

Mobile safe
IMG

The desktop fixed item is protected, but the layout is allowed to become a simpler mobile structure.

Error 5

Using flex-shrink:0 to hide a bigger layout problem

Sometimes disabling shrinking is correct. Other times it only moves the problem somewhere else. If the layout is too wide because of huge gaps, fixed widths, padding, long content, or too many columns, flex-shrink:0 can create overflow instead of solving the root issue.

Risky code

Overflow risk 
.card {
  flex: 0 0 360px;
}

.row {
  display: flex;
  gap: 32px;
  padding: 32px;
}

Why this can backfire

Three cards at 360px, plus gaps and padding, can easily exceed mobile width. The items no longer shrink, so the page may scroll sideways.

Better responsive pattern

Flexible cards 
.row {
  display: flex;
  flex-wrap: wrap;
  gap: 24px;
}

.card {
  flex: 1 1 min(100%, 280px);
  min-width: 0;
}

Why this is safer

This lets cards wrap and adapt instead of forcing every item to stay fixed in one row. Use protected fixed widths only when the design truly needs them.

Fast practical rule

If a flex item is shrinking even with a fixed width, do not keep increasing the width. First ask: is the item allowed to shrink? If it must stay fixed, use flex-shrink:0 or flex:0 0 size. Then make sure the neighboring flexible content has min-width:0 and the layout stacks or wraps on small screens.

When to use flex-shrink:0

Use flex-shrink:0 when an item has a meaningful visual size that should not be compressed. Common examples include a fixed sidebar, icon rail, media thumbnail, avatar column, label column, pricing card width, or control panel.

The important detail is intent. If the item’s width is part of the interface structure, protect it. If the item should adapt to available space, do not lock it too aggressively.

Good fixed sidebar pattern

Stable 
.page-layout {
  display: flex;
  gap: 32px;
  align-items: flex-start;
}

.sidebar {
  flex: 0 0 300px;
}

.main {
  flex: 1 1 auto;
  min-width: 0;
}

This pattern clearly protects the sidebar while letting the main column adapt.

Good media object pattern

Image safe 
.media-card {
  display: flex;
  gap: 16px;
}

.media-card__image {
  flex: 0 0 96px;
}

.media-card__image img {
  display: block;
  width: 100%;
  height: auto;
}

.media-card__body {
  flex: 1 1 auto;
  min-width: 0;
}

Why image columns get squeezed

Image columns often shrink because the image wrapper is a flex item too. The image itself may be responsive, but its parent still needs a protected flex basis if the thumbnail must keep a stable size.

This is especially common in blog cards, product cards, author boxes, comments, profile rows, and notification components.

Debug checklist

  • Confirm the element is actually a flex item: its parent must have display:flex or display:inline-flex.
  • Remember that flex items default to flex-shrink:1.
  • If the item must keep its width, add flex-shrink:0.
  • For a stronger pattern, use flex:0 0 300px instead of relying only on width:300px.
  • Add min-width:0 to the flexible content column beside the protected item.
  • Check for long words, URLs, code strings, buttons, images, or tables inside the flexible content.
  • Use wrapping or a mobile breakpoint when the protected row is too wide for small screens.
  • Do not solve the symptom with overflow:hidden unless hidden content is actually acceptable.
  • Check gaps and padding. A fixed item plus large gaps can break the available space calculation.
  • Use DevTools to inspect computed flex-basis, flex-shrink, and final rendered width.
Best first move Add flex-shrink:0 to the fixed item and retest.
Most common false fix Making the width bigger when the real issue is that shrinking is still enabled.
Most overlooked cause The neighboring content column may need min-width:0.
Production mindset Protect fixed items only when they truly need protection. On mobile, allow the layout to stack, wrap, or simplify.

Related fixes that can help

If your flex item is shrinking because of a larger layout issue, these FrontFixer guides are the next places to check.

Fix Flexbox not centering If the same flex layout is also failing to align items the way you expect. Read this fix
Why is my text overflowing outside the box? If long content inside the flexible column is forcing the row wider. Read this fix
Horizontal scroll on mobile? If protecting the fixed item creates unwanted sideways scrolling on small screens. Read this fix

Final takeaway

A flex item shrinking even with a fixed width usually means Flexbox is doing exactly what it was allowed to do. The default flex-shrink:1 tells the browser it may reduce the item when the row gets tight. A fixed width alone does not always protect that item.

Start with flex-shrink:0 or the stronger flex:0 0 300px pattern. Then add min-width:0 to the neighboring flexible content and use a responsive breakpoint when the row becomes too narrow. Once you control both the protected item and the flexible item beside it, this Flexbox bug becomes predictable instead of maddening.

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

CSS Grid Breaks on Safari? Fix the Real Browser Bug

by

CSS Grid breaks on Safari when a grid that looks fine in Chrome suddenly overflows, stretches, wraps strangely, or creates horizontal scroll on iPhone, iPad, or Safari desktop.

Browser CSS Fix

CSS Grid Breaks on Safari? Fix the Real Browser Bug

When CSS Grid breaks on Safari but works in Chrome, the bug usually feels unfair. You build a clean grid, test it in Chrome, resize the viewport, and everything looks fine. Then the same layout opens on iPhone or Safari and one card stretches, columns overflow, the page gets sideways scroll, or the grid refuses to collapse cleanly. Most of the time, Safari is not simply “ignoring Grid.” It is exposing a hidden sizing problem: fragile 1fr tracks, grid children that refuse to shrink, media that is wider than the column, long content, or an auto-fit minimum that is too wide for real mobile screens.

Browse All Fixes Explore CSS Fixes
  • Safari Grid bug
  • iPhone layout issue
  • 1fr sizing trap
  • Horizontal scroll risk

What the bug looks like

Safari shows columns overflowing, cards becoming wider than their row, gaps looking wrong, or the entire page gaining horizontal scroll even though Chrome looked normal.

Why it happens

Safari often reveals minimum-size and intrinsic-sizing problems that were already present in the grid. Chrome may make the same layout look more forgiving during development.

What usually fixes it

Replace fragile track sizing, let children shrink, constrain media, and keep long content from forcing the grid wider than its container.

Why Safari grid bugs are usually not random

A CSS Grid bug in Safari often looks like a browser mystery because the same CSS appears to work elsewhere. But browser differences usually expose a deeper layout truth: the grid is being asked to distribute space, while one child is quietly refusing to become smaller.

The most common trap is assuming that 1fr means “always split the available space equally.” In real layouts, the content inside the track still matters. If a grid child has a long URL, a wide image, a button with white-space:nowrap, a code block, or a nested flex row, the grid track may become wider than expected.

That is why this issue often connects with other FrontFixer fixes like CSS Grid breaking on mobile, horizontal scroll on mobile, and text overflowing outside the box.

Error 1

Using plain 1fr when content can overflow

The classic Safari Grid issue starts with a layout that looks harmless. Two columns. A gap. Cards inside. Then one card contains a long string, a button, or a nested component, and Safari lets that content pressure the track wider than you expected.

Broken code

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

.card {
  padding: 24px;
}

Broken visual result

Safari exposes overflow
Normal card
VeryLongUnbreakableGridContent

The second card refuses to shrink, so the grid becomes wider than the visible area.

Correct code

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

.card {
  min-width: 0;
}

Fixed visual result

Grid can shrink
Normal card
VeryLongUnbreakableGridContent

minmax(0,1fr) and min-width:0 tell the grid that the column and child are allowed to shrink.

Error 2

Forgetting min-width:0 on grid children

This is one of the most important CSS layout fixes because it is invisible until the layout becomes tight. Grid children can have an automatic minimum size. That means a child may protect its content instead of shrinking to fit the available column. Safari can make this feel more dramatic.

Broken code

Auto minimum 
.grid {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
}

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

Why this still breaks

The text may be allowed to wrap, but the grid item itself can still resist shrinking because its minimum size is not reset. That pressure can create Safari overflow.

Correct code

Child can shrink 
.grid {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
}

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

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

Why this is safer

The grid track can shrink, the child can shrink, and the content can wrap. All three layers work together instead of fighting each other.

Error 3

Using an auto-fit minimum that is too wide for real phones

A grid pattern can look modern and still break on smaller screens. The common pattern repeat(auto-fit,minmax(320px,1fr)) may fail when the viewport is narrow, the wrapper has padding, and the grid also has gaps. Safari on iPhone makes this painfully visible.

Broken code

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

Broken mobile result

Too wide
Card one
Card two

Correct code

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

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

Fixed mobile result

Fits phone
Card one
Card two
Error 4

Images, embeds, or media are wider than the grid item

Large images, videos, iframes, SVGs, and embeds can silently force a grid item to become wider than expected. If the media is not constrained, Safari may let the media pressure the entire grid.

Broken code

Media overflow 
.card img {
  width: auto;
}

Broken media result

Image pushes width

Correct code

Media contained 
img,
video,
iframe {
  max-width: 100%;
}

img,
video {
  height: auto;
  display: block;
}

Fixed media result

Image stays inside
Error 5

Long content inside the grid has no local overflow rule

Code blocks, tables, long URLs, and unbroken strings are dangerous inside CSS Grid. The right fix is not always to make the whole page hide overflow. Often the content itself needs a local scroll area or wrapping rule.

Broken code

Global pressure 
pre {
  white-space: pre;
}

.grid {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
}

Why this breaks

The code block keeps its full line width. If that width is larger than the grid column, it can force the column and page wider.

Correct code

Local scroll 
pre {
  max-width: 100%;
  overflow-x: auto;
}

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

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

Why this is cleaner

The code block handles its own overflow locally, while the grid remains inside the page layout.

Fast practical rule

If CSS Grid breaks on Safari but works in Chrome, test minmax(0,1fr) and min-width:0 before rewriting the whole component. Then check media, long content, auto-fit minimums, and accidental overflow. Most Safari Grid bugs are really hidden sizing bugs.

Why minmax(0,1fr) is the strongest Safari Grid fix

minmax(0,1fr) tells the browser that the grid track is allowed to shrink down to zero before free space is distributed. That sounds technical, but the practical meaning is simple: the content does not get to secretly decide the minimum column width.

A plain 1fr track can still be influenced by the minimum size of the content inside it. When you use minmax(0,1fr), you make the grid track more honest about the available space.

Production-safe grid pattern

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

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

.grid img,
.grid video,
.grid iframe {
  max-width: 100%;
}

Debug checklist

  • Test the page in Safari desktop and on a real iPhone if possible.
  • Check whether the page becomes wider than the viewport.
  • Replace fragile 1fr columns with minmax(0,1fr).
  • Add min-width:0 to direct grid children.
  • Constrain images, videos, iframes, embeds, and SVGs with max-width:100%.
  • Check for long URLs, code blocks, button labels, or unbroken text inside grid items.
  • Use overflow-wrap:anywhere where unpredictable text can appear.
  • Review auto-fit and auto-fill minimum values on small screens.
  • Use local overflow-x:auto for tables and code blocks instead of hiding overflow on the entire page.
  • Inspect nested flex layouts inside grid items, because they may also need min-width:0.
Best first move Add min-width:0 to grid children and replace plain 1fr with minmax(0,1fr).
Most common false fix Blaming Safari immediately or hiding the entire page overflow with overflow-x:hidden.
Most overlooked cause One child inside the grid is wider than the track and quietly controls the whole layout.
Better mindset Safari is often showing you the weak point in your sizing logic, not inventing the bug from nowhere.

Related fixes that can help

If the Safari Grid issue is part of a bigger responsive or overflow problem, these FrontFixer fixes are the next places to check.

Fix CSS Grid breaking on mobile If your grid fails when the available screen width gets tight. Read this fix
Fix overflow causing horizontal scroll If Safari creates unwanted sideways scrolling on mobile. Read this fix
Text overflowing outside the box If one long URL, token, code string, or label is forcing the grid wider. Read this fix

Final takeaway

CSS Grid breaks on Safari when the layout depends on flexible tracks but the content inside those tracks is not allowed to shrink safely. Safari may expose the issue more clearly than Chrome, especially on iPhone and iPad, but the fix is usually in the grid structure.

Start with minmax(0,1fr). Add min-width:0 to grid children. Constrain media. Give long content a wrapping or local overflow rule. Then retest in Safari. Once the grid, the child, and the content all have permission to fit inside the available width, Safari Grid bugs become much less mysterious.

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

Gap Under Image CSS? Fix the Invisible Layout Space

by

Gap under image CSS problems usually happen because an image is still behaving like inline text, so the browser reserves baseline space below it.

CSS Layout Fix

Gap Under Image CSS? Fix the Invisible Layout Space

A small gap under an image can make a card, banner, thumbnail, figure, or hero section look slightly broken. The confusing part is that the image may have no margin, the wrapper may have no padding, and the layout can still show a thin strip under the image. In most cases, that gap is not a box-model problem. It is inline baseline spacing.

Browse All Fixes Explore CSS Fixes
  • Image baseline gap
  • Card image spacing
  • One-line CSS fix
  • Responsive image reset

What the bug looks like

A thin strip of parent background appears under the image, especially inside cards, wrappers, figures, galleries, product thumbnails, and hero sections.

Why it happens

The image sits on the inline text baseline. The gap is the browser preserving room for text descenders below that baseline.

What usually fixes it

Set the image to display:block, or use vertical-align:bottom if the image must remain inline.

Why gap under image CSS bugs happen

Images feel like boxes, but HTML does not automatically treat them as block-level layout boxes. By default, an image is an inline replaced element. That means it participates in a line box, similar to inline text. Because inline text needs space below the baseline for descenders, the browser can reserve a little empty space under the image.

This is why the bug often looks impossible at first. You inspect the image, the wrapper, and the card. You do not see margin. You do not see padding. But the gap is still there because the spacing is coming from inline formatting behavior, not from the normal margin or padding you expected.

Error 1

The image is still inline

This is the classic version of the bug. The image fills the wrapper, but the browser still treats it like inline content sitting on a baseline. The container background shows through below the image.

Broken code

Inline image trap 
<div class="image-card">
  <img src="photo.jpg" alt="Example image">
</div>
.image-card {
  background: #111827;
}

.image-card img {
  width: 100%;
  height: auto;
}

Broken visual result

Baseline space visible
Image behaves like inline text Gap visible

The dark strip under the image is not a margin. It is the inline baseline gap showing through.

Correct code

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

Fixed visual result

Gap removed
Image behaves like a block No baseline gap

Once the image becomes a block, it no longer reserves text descender space under itself.

Error 2

You are debugging margin or padding instead of baseline spacing

Developers often lose time removing margin, changing padding, setting fixed heights, or hiding overflow. Those changes may accidentally hide the symptom, but they do not explain the real cause. The root issue is usually the inline formatting context.

Wrong direction

False fix 
.image-card {
  padding-bottom: 0;
  margin-bottom: 0;
  overflow: hidden;
}

What is really happening

The image sits on a line baseline. The browser reserves room below that baseline for text descenders.

Correct direction

Change image behavior 
.image-card img {
  display: block;
}

Why this is cleaner

Instead of fighting the wrapper, you change the image itself from inline behavior to block behavior. That removes the baseline relationship directly.

Use margin and padding when you want intentional spacing. Use display:block when you want an image to fit flush inside a visual container.

Error 3

The image is inside a card, so the tiny gap becomes obvious

The baseline gap is always small, but card designs make it visible. Cards often have borders, shadows, rounded corners, dark backgrounds, or cropped image areas. That makes a tiny gap look like a broken visual detail.

Broken card pattern

Card media gap 
.card {
  overflow: hidden;
  border-radius: 18px;
  background: #ffffff;
}

.card img {
  width: 100%;
  height: auto;
}

Broken card result

unexpected image gap
Product card The tiny dark line makes the whole card feel less polished.

Correct card pattern

Clean card media 
.card {
  overflow: hidden;
  border-radius: 18px;
  background: #ffffff;
}

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

Fixed card result

gap removed
Product card The media area now sits cleanly against the card content.
Error 4

The image must stay inline, but baseline alignment is still wrong

Sometimes an image really does need to remain inline with text, icons, badges, emoji-like graphics, or small UI media. In that case, display:block may not be the right fix. Instead, use vertical-align to control the inline alignment.

Baseline default

Inline alignment 
.inline-thumb {
  display: inline-block;
  vertical-align: baseline;
}

Inline element aligned to baseline

Text before text after

The visual may feel slightly low or leave awkward space depending on the surrounding text.

Better inline alignment

Bottom aligned 
.inline-thumb {
  display: inline-block;
  vertical-align: bottom;
}

Inline element aligned more cleanly

Text before text after

This keeps the element inline but changes how it sits against the text line.

Error 5

You fixed the image gap but forgot responsive image safety

Once you fix the tiny baseline gap, do not stop there. Most real image layouts also need a safe responsive image reset. Without max-width:100% and height:auto, images can create width and overflow problems on smaller screens.

Incomplete reset

Only fixes gap 
img {
  display: block;
}

Better reusable reset

Gap + responsive safety 
img,
video {
  display: block;
  max-width: 100%;
  height: auto;
}

Why this matters

The image gap bug is a spacing issue. Responsive image overflow is a width issue. They are different bugs, but they often appear in the same card, gallery, hero, or article layout.

Fast practical rule

If there is a tiny gap under an image and no margin or padding explains it, add display:block to the image. If that removes the gap, the issue was inline baseline spacing. For inline images that must stay inline, use vertical-align:bottom or vertical-align:middle.

Best default image pattern for real layouts

In production CSS, many teams use a small image reset because images inside cards, articles, product grids, and responsive layouts usually need predictable behavior. This does not mean every image must always be block-level, but it is a strong default for layout images.

If an image is part of the structure of a card, section, hero, thumbnail, gallery, or figure, display:block usually makes the layout easier to control.

Recommended global image reset

Production default 
img,
picture,
video,
canvas,
svg {
  display: block;
  max-width: 100%;
}

img,
video {
  height: auto;
}

Figure with caption pattern

Article images 
<figure class="media">
  <img src="layout.jpg" alt="Layout example">
  <figcaption>Example caption</figcaption>
</figure>
.media img {
  display: block;
  width: 100%;
  height: auto;
}

.media figcaption {
  padding: 12px 16px;
}

Why captions should not depend on accidental spacing

A caption should have intentional spacing from your CSS. It should not be separated from the image because the browser happened to reserve baseline descender space.

Making the image block-level gives you full control: the image ends where it should, and the caption spacing comes from figcaption, not from hidden inline behavior.

Debug checklist

  • Inspect the image and wrapper to confirm there is no obvious margin or padding creating the gap.
  • Check whether the gap is small, directly under the image, and the same color as the parent background.
  • Add display:block to the image and retest.
  • If the image must remain inline, try vertical-align:bottom or vertical-align:middle.
  • Check the parent line-height if the image is mixed with text.
  • Use max-width:100% and height:auto for responsive image safety.
  • For cards, make the media image block-level before adjusting card padding or wrapper height.
  • For figures, control caption spacing with figcaption padding or margin, not accidental baseline space.
Best first move Add display:block to the image.
Most common false fix Removing random padding, margin, or height from the wrapper.
Most overlooked cause Images are inline by default, even when they visually look like layout blocks.
Better mindset A tiny image gap is usually a line-box behavior, not a broken card.

Related fixes that can help

If the image gap is part of a bigger layout issue, these FrontFixer guides are the next places to check.

Why is my image stretching or squashed in CSS? If the image gap appears together with distorted, squeezed, or badly cropped images. Read this fix
Fix overflow causing horizontal scroll If images or wrappers are making the page wider than the screen. Read this fix
Fix container width problems If the image sits inside a wrapper that feels too wide, too narrow, or misaligned. Read this fix

Final takeaway

Gap under image CSS bugs usually happen because the image is still inline by default. Inline content sits on a text baseline, and the browser reserves a little room below that baseline for descenders. That small reserved area is the mysterious strip you see under the image.

The fastest fix is usually display:block. For layout images inside cards, figures, banners, galleries, and responsive components, combine it with max-width:100% and height:auto. Once you understand that the gap is baseline spacing, this bug becomes simple instead of mysterious.

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 Image Stretching or Squashed in CSS?

by

Image Layout Fix

Why is my image stretching in CSS?

Why is my image stretching in CSS? Most of the time, the image file is not the problem. The real issue is that the container has one shape, the image has another shape, and your CSS is forcing both width and height in a way that destroys the original proportion.

Browse All Fixes See the Difference
  • Very common beginner CSS bug
  • Usually caused by forced width + height
  • Fix with object-fit and aspect-ratio

The image problem in one picture

The image below is represented by the same visual content in three states: broken, fixed, and premium. The difference is not the image file. The difference is how the CSS handles the image inside the container.

× Error: stretched image
The image is being forced into a wide, short box. It fills the space, but the proportion is destroyed.
✓ Better: object-fit cover
The image keeps its proportion. The browser crops extra parts instead of squashing the photo.
★ Premium: stable media card
Responsive image card

A stable image ratio, clean crop, and predictable layout across screen sizes.

What the bug looks like

The image looks normal in the file, but inside the website it becomes stretched sideways, squeezed vertically, too tall, too flat, or distorted inside a card.

Why it happens

The browser is trying to obey your CSS box. If you force the image into a shape that does not match its natural proportion, distortion can happen.

What usually fixes it

Use object-fit, set a stable aspect-ratio, and avoid forcing images to obey both width and height without a fitting strategy.

Why images stretch even when the file is fine

Every image has a natural shape. A landscape image may be 1600×900. A portrait image may be 900×1200. A square image may be 1000×1000. That natural relationship between width and height is the image’s aspect ratio.

The problem starts when your CSS forces the image into a container with a different shape. A wide banner, a square card, or a short product tile may ask the browser to make the image fit a box that does not match the original file.

This is why image stretching often appears inside cards, CSS Grid layouts, Flexbox rows, and responsive sections. If the surrounding layout is also unstable, check related FrontFixer guides like Fix CSS Grid Breaking on Mobile and Fix container width problems.

The simple mental model

The image has a natural shape The file already has a width-to-height relationship before your CSS touches it.
The container has a layout shape Your card, hero, grid item, or banner creates a visual box on the page.
Distortion happens when the two fight If CSS forces the image to fill a mismatched box without object-fit, the image may stretch.

Common broken version

Distorts the image 
.card img {
  width: 100%;
  height: 220px;
}

Why this fails

This code tells the image to become exactly as wide as the card and exactly 220px tall. But it does not tell the browser how to preserve the image’s original proportion.

So the browser may squeeze or stretch the image until it fits the box. The result can look like a photo was pulled sideways or flattened from the top.

This is not a mysterious browser bug. It is usually a missing fitting rule.

Recommended baseline fix

Object-fit cover

For most cards, thumbnails, hero images, and visual previews, this is the clean baseline pattern. 

.card-media {
  aspect-ratio: 16 / 9;
  overflow: hidden;
  border-radius: 18px;
}

.card-media img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

Visual example: error

Bad CSS
The image fills the area, but it has been flattened. This is what happens when CSS forces dimensions without a fitting rule.

The CSS that causes it

Forced dimensions 
.hero-image img {
  width: 100%;
  height: 180px;
}

The better version

Keeps proportion 
.hero-image {
  aspect-ratio: 16 / 9;
  overflow: hidden;
}

.hero-image img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

Visual example: improved

Better CSS
The image now keeps its natural proportion. The browser crops the extra area instead of stretching the image.

object-fit: cover vs object-fit: contain

This is where many tutorials stop too early. They say “use object-fit” but do not explain which value to use.

Use object-fit: cover when the image should fill the container, even if the browser has to crop a little. This is common for cards, hero sections, thumbnails, blog previews, and product grids.

Use object-fit: contain when the full image must remain visible, even if empty space appears around it. This is common for logos, product photos, diagrams, icons, and screenshots.

CSS value What it does Best use case
object-fit: cover Fills the container while preserving image proportion. Some parts may be cropped. Cards, thumbnails, hero images, previews, blog images.
object-fit: contain Keeps the entire image visible. Empty space may appear inside the container. Logos, product shots, screenshots, diagrams, UI images.
object-fit: fill Forces the image to fill the box even if it distorts the image. Rarely ideal. This is often the cause of the stretching problem.
object-fit: none Keeps the image’s original size and may crop the image inside the box. Special cases where you intentionally control visible image position.

Fast practical rule

If the image is decorative or part of a card layout, start with object-fit: cover. If the image contains important information that must not be cut off, start with object-fit: contain.

Premium version

Production pattern
Stable responsive media card

The media area keeps a predictable ratio, the image does not distort, and the layout remains clean across desktop and mobile.

Premium card pattern

Reusable component 
.feature-card {
  border: 1px solid #e5e7eb;
  border-radius: 24px;
  overflow: hidden;
  background: #fff;
}

.feature-card__media {
  aspect-ratio: 16 / 10;
  overflow: hidden;
}

.feature-card__media img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

When aspect-ratio is the missing piece

object-fit tells the image how to behave inside the box. But aspect-ratio helps define the shape of the box itself.

Without a stable media ratio, cards in a grid may jump around, images may become different heights, and responsive layouts may feel messy. This is especially common in CSS Grid and Flexbox layouts where content changes from card to card.

If your image bug appears only when cards wrap or columns change, the issue may overlap with Fix Flexbox not centering or Fix responsive design not working.

Stable media ratio

Less layout shift 
.post-card__image {
  aspect-ratio: 4 / 3;
  overflow: hidden;
}

.post-card__image img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

Use cover for visual consistency

If all cards need the same clean shape, cover is usually the best choice because it fills the frame and avoids distortion.

Use contain for important full images

If cropping would remove important information, like text in a screenshot or a product detail, use contain.

Use display:block on images

This also avoids the classic inline-image baseline gap, which can create a mysterious space under images.

Logo or screenshot pattern

Object-fit contain 
.logo-box {
  aspect-ratio: 16 / 9;
  display: grid;
  place-items: center;
  background: #f8fafc;
}

.logo-box img {
  width: 80%;
  height: 80%;
  object-fit: contain;
  display: block;
}

Why contain is better for logos

A logo should usually never be cropped. If you use cover on a logo, part of the mark or text may disappear. If you force width and height, the logo may stretch and look unprofessional.

For logos, screenshots, diagrams, and UI examples, contain is often safer because it keeps the full image visible.

Debug checklist

  • Check whether the image has both width and height forced.
  • Inspect the container size and see whether its ratio matches the image ratio.
  • Add object-fit: cover when the image should fill the container.
  • Add object-fit: contain when the full image must remain visible.
  • Use aspect-ratio on the media wrapper to create stable cards.
  • Add display:block to images to avoid baseline spacing issues.
  • Test the image inside mobile breakpoints, not only on desktop.
  • Check whether CSS Grid or Flexbox is changing the card width unexpectedly.
  • Avoid using random fixed heights unless the image has a clear fitting strategy.
  • Use DevTools to compare the image’s rendered size with its natural size.
Best first move Wrap the image in a media container, set an aspect ratio, then use object-fit on the image.
Most common false fix Cropping the image manually in an editor instead of fixing the CSS behavior.
Most overlooked cause A responsive container changes shape on mobile, and the image is forced to follow it.
Better mindset Do not ask only “what size should the image be?” Ask “how should this image fit inside this box?”

Common mistakes that make images look distorted

Mistake Why it breaks Better fix
Using fixed width and fixed height directly on the image The image may be forced into a shape that does not match its natural ratio. Use a wrapper with aspect-ratio and apply object-fit to the image.
Using height:100% without a controlled parent height The browser may calculate a height you did not expect or stretch the image inside a strange container. Define the media wrapper clearly, then make the image fill that wrapper.
Using object-fit: fill fill can distort the image because it forces both dimensions. Use cover or contain depending on whether cropping is acceptable.
Forgetting mobile breakpoints A card that works on desktop may become too narrow or tall on mobile. Test the image container at mobile widths and adjust aspect ratio when needed.
Using the same rule for photos, logos, and screenshots Different image types need different fitting behavior. Use cover for photos and previews; use contain for logos and screenshots.

Related fixes that can help

If your image stretching problem is connected to a bigger layout issue, these FrontFixer guides are the next places to check.

Fix CSS Grid Breaking on Mobile If your images stretch only when grid columns collapse or change width. Read this fix
Fix container width problems If the image looks wrong because the parent container is too wide, too narrow, or unstable. Read this fix
Fix overflow causing horizontal scroll If images are also creating sideways scrolling on mobile. Read this fix

Final takeaway

Why is my image stretching in CSS? Usually because the browser is being forced to make an image fit a box with the wrong proportion. The image file is fine. The fitting strategy is missing.

Start with a media wrapper, give that wrapper a stable aspect-ratio, and use object-fit: cover or object-fit: contain depending on whether the image should crop or remain fully visible. Once you understand the difference, distorted images become one of the easiest front-end bugs to fix.

Want more fixes like this?

Explore the full FrontFixer fixes library and keep debugging real CSS, HTML, and responsive layout problems with practical examples.

Browse All Fixes See the Difference

Why Is My Dropdown Getting Cut Off?

by

Dropdown getting cut off problems usually happen when a parent clips overflow, a stacking context traps the menu, or the dropdown is rendered inside a wrapper that was never meant to let children escape.

Dropdown Fix

Why is my dropdown getting cut off even with z-index?

If your dropdown menu opens but gets clipped, hidden, or cut in half, the real problem is usually not that your z-index number is too small. Most dropdown bugs come from overflow:hidden, overflow:auto, a clipped parent, a new stacking context, or a menu rendered inside the wrong part of the DOM.

Browse CSS Fixes Explore All Fixes
  • Dropdown clipping
  • Overflow traps
  • Stacking contexts
  • Real UI debugging

What the bug looks like

The dropdown opens, but only part of the menu appears. It may be cut at the bottom of a card, hidden inside a table wrapper, or trapped behind another section.

Why it happens

Dropdowns need visual escape space and correct layering. If a parent clips overflow or creates a new layer boundary, the menu cannot behave like a free floating surface.

What usually fixes it

First separate clipping from layering. If the menu is physically cut off, fix overflow. If it appears behind another element, fix stacking context and z-index.

The mistake: treating every dropdown bug like a z-index bug

A dropdown can disappear for two very different reasons. It can be behind another element, which is a layering issue. Or it can be physically clipped by its parent, which is an overflow issue. A giant z-index:999999 only helps with some layering problems. It does not let a child escape a parent that is cutting visual overflow.

That is why dropdown bugs feel so frustrating. The menu looks like it should float above the page, but the browser still respects the boundaries created by the surrounding layout.

Error 1

Parent overflow is clipping the dropdown

This is the classic dropdown trap. The menu has position:absolute and a huge z-index, but one parent has overflow:hidden. The parent becomes a visual box cutter. The dropdown cannot draw outside that box.

Broken code

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

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

Broken visual result

Cut by parent
Options ▾
parent edge

The menu exists, but the parent cuts it off before the full dropdown can become visible.

Correct code

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

.dropdown-menu {
  position: absolute;
  top: 100%;
  left: 0;
  z-index: 20;
}

Fixed visual result

Menu can escape
Options ▾

Once the parent is no longer clipping the menu, the dropdown can render outside the trigger box.

Error 2

The dropdown is hidden behind another section

This is a real z-index problem, but only after you confirm the menu is not being clipped. If the dropdown is fully visible but appears underneath a neighboring section, header, card, or banner, the menu is losing the stacking battle.

Broken code

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

.next-section {
  position: relative;
  z-index: 5;
}

.dropdown-menu {
  position: absolute;
  z-index: 2;
}

Broken visual result

Behind section
Next section is above

The menu is not cut by overflow. It is losing against another positioned layer.

Correct code

Higher context 
.nav {
  position: relative;
  z-index: 50;
}

.dropdown-menu {
  position: absolute;
  z-index: 60;
}

Fixed visual result

Menu wins layer

The dropdown belongs to a higher positioned context, so it can sit above the next section.

Error 3

A stacking context traps the menu

A dropdown can have a huge z-index and still lose if it is inside a parent stacking context. Properties like transform, filter, opacity, isolation:isolate, and sometimes will-change can create a layer boundary. The dropdown then competes only inside that boundary.

Broken code

Trapped context 
.header-wrap {
  transform: translateZ(0);
}

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

Why this feels impossible

You keep increasing z-index, but the dropdown never escapes. That happens because the menu is not competing against the whole page. It is competing inside the stacking context created by its parent.

If the next section belongs to a higher stacking context, the dropdown can still appear below it even with a massive number.

Error 4

The dropdown is inside a slider, table, or scroll wrapper

Some components clip overflow intentionally. Sliders hide offscreen slides. Responsive tables create horizontal scroll containers. Cards often use overflow:hidden for rounded corners. If your dropdown lives inside one of those wrappers, it may need a structural fix instead of a small CSS tweak.

Classic broken setup

Component clips 
.table-scroll,
.slider-track,
.card {
  overflow: hidden;
}

.dropdown-menu {
  position: absolute;
  top: 100%;
}

The better fix

If the wrapper must keep overflow hidden, do not fight that wrapper forever. Move the dropdown outside the clipped element, render it in a higher layer container, or restructure the component so the menu is not trapped by the scrolling or clipping surface.

Advanced pattern

Render the dropdown in a higher layer when needed

In real apps, dropdowns, tooltips, popovers, and menus are often rendered into a dedicated layer near the end of the document. This keeps them away from clipped cards, scroll wrappers, and local stacking contexts.

Layer container idea

Portal style 
<div class="app">
  <main>...page content...</main>

  <div class="ui-layer">
    <div class="dropdown-menu">...</div>
  </div>
</div>

Structural visual result

Dedicated UI layer
Dropdown / tooltip / popover layer

The menu is no longer trapped inside the clipped component that triggered it.

Fast practical rule

If your dropdown is getting cut off, do not start by adding bigger z-index numbers. First ask: is the menu clipped or layered behind something? If it is clipped, inspect parent overflow. If it is layered behind something, inspect stacking context. Those are different bugs.

Safer dropdown baseline

Production-minded 
.nav {
  position: relative;
  z-index: 50;
  overflow: visible;
}

.nav-item {
  position: relative;
}

.dropdown-menu {
  position: absolute;
  top: calc(100% + 8px);
  left: 0;
  min-width: 220px;
  z-index: 60;
}

Why this pattern is safer

The outer navigation has a meaningful stacking level. The item creates a predictable positioning anchor. The dropdown has a clear placement and does not rely on a random massive number. Most importantly, the parent is not clipping the menu.

This does not solve every app architecture, but it gives you a clean baseline before moving to a portal-style or higher-layer solution.

Debug checklist

  • Inspect the dropdown parent chain for overflow:hidden, overflow:auto, and overflow:scroll.
  • Temporarily set suspicious parents to overflow:visible to see whether the menu stops getting cut off.
  • Check whether the dropdown is physically clipped or simply behind another element.
  • Verify the trigger wrapper has a predictable positioning context, usually position:relative.
  • Verify the dropdown has intentional placement, usually position:absolute, top:100%, and left:0.
  • Inspect parents for stacking-context creators like transform, filter, opacity, isolation, and will-change.
  • Check whether the menu is inside a carousel, table wrapper, slider, card, or scroll container that must clip overflow.
  • If the parent must clip overflow, move the dropdown outside that clipped surface instead of fighting the wrapper.
Best first move Use DevTools to toggle parent overflow rules before changing z-index.
Most common false fix Setting z-index:999999 while a parent is still physically clipping the menu.
Most overlooked cause The dropdown lives inside a component that intentionally hides overflow for design reasons.
Better mindset Dropdown bugs are usually structure bugs. Layering is only one part of the diagnosis.

Related fixes that can help

If your dropdown problem connects to layers, positioning, overflow, or click behavior, these FrontFixer guides are the next places to check.

Fix z-index not working If the dropdown is not clipped, but another element still appears above it. Read this fix
Fix overflow causing horizontal scroll If overflow rules around the dropdown are also creating layout or mobile scroll problems. Read this fix
Why is my button not clickable? If the dropdown opens but its menu items cannot be clicked. Read this fix

Final takeaway

A dropdown getting cut off is rarely solved by a bigger z-index alone. The real fix starts by identifying whether the menu is clipped by overflow, trapped inside a stacking context, or rendered inside a component that cannot allow visual escape.

Fix clipping first, layering second, and structure third. Once you separate those three problems, dropdown menus become much easier to debug and much less mysterious.

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 Fixed Header Covering Content?

by

A fixed header covers content because position:fixed removes the header from normal document flow. The content below it does not automatically move down, so the first section, page title, or anchor target can slide underneath the header.

Fixed Header Layout Fix

Why Is My Fixed Header Covering Content?

A fixed header can look normal at first, but then the hero title sits behind it, anchor links land too high, or the top of the page feels hidden. The browser is not making a mistake. A fixed element is pinned to the viewport and no longer reserves layout space in the document.

Browse Responsive Fixes Browse All Fixes
  • Fixed header overlap
  • Anchor link offset
  • Sticky vs fixed layout

What the bug looks like

The page title hides behind the header, the hero looks cut off, or clicking a menu link lands with the heading covered.

Why it happens

Fixed elements do not reserve space in normal layout. The content starts at the top as if the header were not there.

What fixes it

Add a deliberate top offset, handle anchor scrolling, adjust mobile header height, or use position:sticky when it fits the layout better.

The simple rule behind fixed header overlap

A fixed header is removed from normal document flow. That means the browser paints the header on top of the viewport, but the next section still begins where it normally would: at the top of the page.

This is why the first heading can look like it disappeared. It is usually not missing. It is sitting underneath the header.

The fastest fix is to measure the real header height and create a matching offset for the content and scroll targets.

Error 1

The content has no top offset

This is the classic fixed header bug. The header is fixed to the top of the viewport, but the main content still begins at the top of the document.

Broken code

No offset 
.site-header {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 80px;
  z-index: 100;
}

main {
  /* no top offset */
}

Broken visual result

Content starts under the header
Fixed header
Hero title is partly hidden The content began at the top, underneath the fixed header.

Correct code

Add top offset 
.site-header {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 80px;
  z-index: 100;
}

main {
  padding-top: 80px;
}

Fixed visual result

Content starts below the header
Fixed header
Hero title is visible The main content now reserves space for the fixed header.
Error 2

The header height is duplicated in several places

Hard-coding the same header height in multiple rules works at first, but it becomes fragile. If the header height changes, one value is easy to forget.

Broken code

Repeated values 
.site-header {
  height: 80px;
}

main {
  padding-top: 80px;
}

section {
  scroll-margin-top: 96px;
}

Broken visual result

Offsets can drift apart
Header 80px
Mixed spacing rules Different values make future changes risky.

Correct code

Single source of truth 
:root {
  --header-height: 80px;
  --header-offset: calc(var(--header-height) + 16px);
}

.site-header {
  height: var(--header-height);
}

main {
  padding-top: var(--header-height);
}

section {
  scroll-margin-top: var(--header-offset);
}

Fixed visual result

One value controls the layout
Header variable
Offsets stay consistent Changing the header height becomes safer.
Error 3

Anchor links land behind the fixed header

You may fix the top of the page and still have broken in-page navigation. The browser scrolls the target to the top of the viewport, where the fixed header is waiting.

Broken code

No scroll offset 
<a href="#features">Features</a>

<section id="features">
  <h2>Features</h2>
</section>

Broken visual result

Anchor target is covered
Fixed header
#features The target lands behind the fixed header.

Correct code

Scroll margin 
section,
h2,
h3 {
  scroll-margin-top: 96px;
}

Fixed visual result

Anchor target has breathing room
Fixed header
#features The target lands below the header instead of behind it.
Error 4

The mobile header is taller than the desktop header

A header that is 72px on desktop may become 112px on mobile after nav items wrap or a second row appears. If the offset stays desktop-sized, mobile content gets covered.

Broken code

Desktop-only offset 
:root {
  --header-height: 72px;
}

main {
  padding-top: var(--header-height);
}

Broken visual result

Mobile header is taller
Fixed header
DocsFixesCSSHTMLResponsive
Content is too high The mobile header grew, but the offset did not.

Correct code

Responsive offset 
:root {
  --header-height: 72px;
}

@media (max-width: 768px) {
  :root {
    --header-height: 112px;
  }
}

main {
  padding-top: var(--header-height);
}

Fixed visual result

Mobile offset matches header
Fixed header
DocsFixesCSSHTMLResponsive
Content starts below The mobile offset now matches the taller header.
Error 5

Using fixed when sticky would be simpler

Many fixed header bugs happen because the header did not need to be fixed in the first place. If the header only needs to stick after reaching the top, position:sticky can be cleaner.

More fragile code

Fixed requires offset 
.site-header {
  position: fixed;
  top: 0;
  height: 80px;
}

main {
  padding-top: 80px;
}

Fixed header behavior

Needs manual compensation
Fixed header
Works, but requires offset Fixed is valid, but you must manage the layout space.

Alternative code

Sticky header 
.site-header {
  position: sticky;
  top: 0;
  z-index: 100;
}

Sticky visual result

Header keeps layout space
Sticky header
Content begins naturally The header still participates in normal document flow before sticking.

Fast practical rule

If a fixed header covers content, do not guess random margins. Measure the real header height, offset the content intentionally, and protect anchor links with a scroll offset.

Recommended baseline

Fixed header foundation

This baseline keeps the header height, page offset, and anchor offset connected through custom properties. 

:root {
  --header-height: 80px;
  --anchor-offset: calc(var(--header-height) + 16px);
}

.site-header {
  position: fixed;
  inset: 0 0 auto 0;
  height: var(--header-height);
  z-index: 100;
}

main {
  padding-top: var(--header-height);
}

section,
h2,
h3 {
  scroll-margin-top: var(--anchor-offset);
}

@media (max-width: 768px) {
  :root {
    --header-height: 104px;
  }
}

Why this baseline helps

It compensates for fixed positioning The main content gets space equal to the header height.
It protects anchor navigation scroll-margin-top keeps headings from landing behind the header.
It handles mobile height changes The same variable can change at mobile breakpoints.
It is easier to maintain You adjust one header value instead of chasing scattered magic numbers.

Debug checklist

  • Check whether the header uses position:fixed.
  • Measure the actual rendered header height in DevTools.
  • Add matching top padding to main, the content wrapper, or the first section.
  • Check whether the header height changes on mobile.
  • Test in-page anchor links like #features, #pricing, or #faq.
  • Use scroll-margin-top or scroll-padding-top for anchor navigation.
  • Check whether a fixed header is really needed or whether position:sticky is enough.
  • Avoid random margin guesses that only work at one screen size.
Best first move Measure the real header height and apply a deliberate top offset to the content.
Most common false fix Increasing z-index when the real problem is that the content starts under the header.
Most overlooked cause Anchor links can still hide headings behind the header even after the first page load looks fixed.
Better mindset Fixed headers are not wrong. They simply require layout compensation because they leave document flow.

When z-index is also involved

Sometimes the header covers content and also sits above dropdowns or modals. In that case, you may be dealing with a layering problem too.

If the issue involves elements appearing behind each other, read Why is my z-index not working?.

When responsive layout is the real problem

If the header only covers content on mobile, the layout may need a mobile-specific header height or responsive offset.

If multiple sections are breaking on mobile, read Why is my responsive design not working?.

When absolute elements are also misplaced

Fixed headers, dropdowns, badges, and menus often appear together. If an overlay is not only covered but also positioned in the wrong place, the parent positioning context may be wrong.

If that sounds familiar, read Why is my absolute positioned element in the wrong place?.

When overflow creates side effects

A fixed header can make layout issues more visible, but horizontal overflow usually comes from a wide element elsewhere on the page.

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

Related fixes that can help

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

Why is my z-index not working? Use this when the fixed header is involved in a layer battle with dropdowns, modals, or overlays. Read this fix
Why is my responsive design not working? Use this when the header only breaks on mobile or multiple sections fail at smaller widths. Read this fix
Why is my absolute positioned element in the wrong place? Use this when an overlay near the header is also anchored to the wrong parent. Read this fix

Final takeaway

A fixed header covers content because it is removed from normal document flow. The page content does not automatically reserve space for it.

Fix the layout by adding a top offset that matches the header height, using scroll offsets for anchor links, adjusting the value on mobile, and considering position:sticky when a fully fixed header is not necessary.

Once the content and scroll targets know the header exists, the overlap bug becomes predictable and easy to avoid.

Need more layout fixes?

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

Responsive Fixes All Fixes

Fix position: sticky not working

by

Position: sticky usually stops working when the sticky element has no offset value, a parent creates the wrong scroll container, or the surrounding layout gives the element no real space to stick.

CSS Sticky Fix

Fix position: sticky not working.

If your sticky header, sidebar, filter bar, table header, or navigation element refuses to stick, the problem is usually not the position:sticky declaration by itself. Sticky only works when the browser can calculate a scroll threshold, a containing area, and enough movement space. If one parent in the chain has the wrong overflow, height, alignment, or scroll behavior, the sticky element can act like normal position:relative.

Browse All Fixes Explore CSS Fixes
  • Sticky headers
  • Sticky sidebars
  • Overflow traps
  • Scroll container bugs

What the bug looks like

The element scrolls away like normal content, sticks only for a tiny moment, stops too early, or behaves differently inside a sidebar, table, header, or dashboard layout.

Why it happens

Sticky is not just a property. It is a relationship between the sticky element, its offset, its ancestors, and the scroll container that controls the page movement.

What usually fixes it

Add a clear offset, remove accidental parent overflow, give the sticky element enough vertical space, and make sure the layout is not stretching the sticky column incorrectly.

The simple rule behind position:sticky

A sticky element behaves like a normal element until the page reaches a defined offset. Then it sticks inside the boundaries of its containing area. That means sticky needs two things at the same time: a normal layout position and a scroll threshold.

This is why position:sticky can feel confusing. It is not fully like fixed, because it does not attach to the viewport forever. It is not fully like relative, because it can temporarily stick during scroll. Sticky lives between normal flow and fixed positioning.

Error 1

The sticky element has no offset value

This is the first thing to check. A sticky element needs a threshold such as top:0, top:20px, or sometimes bottom:0. Without that threshold, the browser has no clear point where sticky behavior should begin.

Broken code

No threshold 
.sidebar {
  position: sticky;
}

Broken visual result

It scrolls away
Sidebar / filter bar

The element is sticky in name, but there is no offset telling the browser when to stick.

Correct code

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

Fixed visual result

It has a point to stick
Sticky sidebar / filter bar

The browser now knows the sticky element should stop when it reaches 24px from the top.

Error 2

A parent has the wrong overflow

This is the sticky bug that wastes the most time. You add position:sticky and top:0, but it still does nothing. Then you inspect the parent chain and discover a wrapper with overflow:hidden, overflow:auto, or overflow:scroll.

Broken code

Overflow trap 
.page-shell {
  overflow: hidden;
}

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

Broken visual result

Wrong scroll container
Sticky element

A parent wrapper is controlling overflow, so sticky may be trapped inside the wrong scroll context.

Correct code

Cleaner parent 
.page-shell {
  overflow: visible;
}

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

Fixed visual result

Parent no longer traps it
Sticky element

Once the accidental overflow rule is removed or moved to the right element, sticky has a cleaner scroll context.

Error 3

The parent is too short for sticky to become visible

Sticky cannot stick forever. It only sticks inside the area of its parent or containing block. If the parent ends almost immediately, the sticky element has no useful distance to travel. This makes sticky look broken even when the CSS syntax is correct.

Broken code

Short parent 
.sidebar-wrap {
  height: 120px;
}

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

Broken visual result

No room to stick
Sticky sidebar
The parent ends too soon, so the sticky behavior has almost no visible runway.

The element may technically enter sticky mode, but there is not enough parent height to see it working.

Correct code

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

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

Fixed visual result

Enough scroll area
Sticky sidebar
The sticky element now has a meaningful containing area during scroll.

Sticky becomes easier to understand when the parent has enough height for the element to move and stop.

Error 4

Grid or Flexbox is stretching the sticky element

Sticky sidebars often fail visually inside Grid or Flexbox because the browser stretches columns or items by default. The sticky element may become as tall as the row, or the sidebar column may not behave like a natural scroll companion. In many real layouts, align-self:start is the missing piece.

Broken code

Stretched item 
.layout {
  display: grid;
  grid-template-columns: 1fr 320px;
}

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

Broken visual result

Layout fights sticky
Sidebar feels stretched or unreliable

The sticky item is inside a layout context, but the alignment is not helping it behave like a compact sticky block.

Correct code

Start aligned 
.layout {
  display: grid;
  grid-template-columns: 1fr 320px;
  gap: 24px;
  align-items: start;
}

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

Fixed visual result

Sticky behaves like a block
Sticky sidebar

Start alignment prevents the sidebar from being stretched in a way that makes sticky behavior harder to reason about.

Error 5

You actually need position:fixed, not sticky

Sometimes sticky is not the right tool. If you want the element to stay attached to the viewport all the time, even after its parent ends, sticky may disappoint you. Sticky is bounded by its container. Fixed positioning is viewport-based.

Wrong expectation

Container bound 
.floating-help {
  position: sticky;
  top: 24px;
}

Why this feels broken

Sticky only sticks inside its containing area. If the parent ends, the sticky behavior ends too. That is correct behavior, not a browser bug.

Use fixed when needed

Viewport bound 
.floating-help {
  position: fixed;
  right: 24px;
  bottom: 24px;
}

When fixed is better

Use fixed for floating help buttons, persistent chat buttons, cookie banners, or elements that should stay attached to the viewport regardless of their parent.

Fast practical rule

If position:sticky is not working, do not start by adding random z-index values. Sticky failure is usually about offset, overflow, scroll context, parent height, or alignment. First check top. Then inspect every parent for overflow. Then check whether the sticky element has enough room to stick.

Sticky vs fixed: the key difference

position:sticky keeps the element in normal flow first, then lets it stick during scroll within a specific boundary. position:fixed removes the element from normal flow and attaches it to the viewport.

This difference matters because a fixed header can cover content if you do not reserve space for it, while a sticky header usually keeps its original space in the document flow.

Good sticky header pattern

Stable 
.site-header {
  position: sticky;
  top: 0;
  z-index: 20;
  background: white;
}

This pattern works well when the header should scroll normally at first and then stay visible at the top while the user continues down the page.

Sticky sidebar pattern

Production-minded 
.content-layout {
  display: grid;
  grid-template-columns: minmax(0, 1fr) 320px;
  gap: 32px;
  align-items: start;
}

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

Why this pattern is safer

The main content column can shrink safely because it uses minmax(0,1fr). The sidebar gets a fixed track, but it is aligned to the start instead of being stretched. The sticky element has a clear top threshold and a predictable layout context.

This is the kind of pattern that survives real pages better than a tiny demo that only works with perfect content.

Debug checklist

  • Confirm the element has position:sticky, not a typo like position: stickyed or a class that is not applied.
  • Add a clear offset such as top:0, top:16px, or top:24px.
  • Inspect every parent for overflow:hidden, overflow:auto, overflow:scroll, or unusual shorthand overflow rules.
  • Check whether the sticky element is inside a parent that is too short for sticky behavior to become visible.
  • If the sticky element is inside Grid or Flexbox, test align-self:start or align-items:start.
  • Check whether another wrapper is creating the real scroll container instead of the page.
  • Do not use sticky when you really need viewport-level behavior. Use position:fixed for persistent floating UI.
  • Add a background and a useful z-index only after sticky is actually working.
Best first move Add top and test again before changing anything else.
Most common false fix Increasing z-index when the real issue is parent overflow or missing offset.
Most overlooked cause The parent is too short, so sticky has no visible area where it can stay stuck.
Better mindset Sticky is a scroll relationship. Debug the parent chain, not just the element.

Related fixes that can help

If sticky is part of a bigger layout problem, these FrontFixer guides are the next places to check.

Why is my fixed header covering content? If you switched from sticky to fixed and now your title, hero, or anchor target is hidden behind the header. Read this fix
Fix z-index not working If your sticky element works but appears behind other sections, overlays, or headers. Read this fix
Fix overflow causing horizontal scroll If you found overflow rules while debugging sticky and now the page is also scrolling sideways. Read this fix

Final takeaway

position:sticky fails when the browser cannot calculate a useful sticky relationship. The usual cause is not a mysterious browser bug. It is a missing offset, a parent with overflow, a container that is too short, or a layout context that stretches or traps the sticky element.

Start with the basics: add top, remove accidental overflow from parents, give the element enough scroll space, and align sticky sidebars to the start in Grid or Flexbox layouts. Once the surrounding structure is clean, sticky becomes predictable instead of frustrating.

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