Why Is My Tooltip Hidden Behind Other Elements?

Tooltip hidden behind elements problems usually happen when the tooltip is clipped by overflow, trapped in a stacking context, placed under a higher z-index element, or positioned relative to the wrong parent.

Tooltip Layer Fix

Why is my tooltip hidden behind other elements?

A tooltip can be coded correctly and still appear behind a card, header, image, dropdown, modal, or nearby section. The problem is rarely the text itself. It is usually a layout-layer problem: overflow:hidden, low z-index, stacking context, transformed parents, or a tooltip that is positioned inside the wrong container.

  • Tooltip z-index
  • Overflow clipping
  • Stacking context
  • Position absolute

What the bug looks like

The tooltip appears cut in half, shows under a card, disappears behind a header, or cannot escape its container.

Why it happens

Tooltips are floating UI, but they are often placed inside normal layout containers that clip or trap them.

What usually fixes it

Remove clipping from the parent, raise the tooltip layer, avoid stacking traps, or render the tooltip in a safer page-level layer.

Error 1

The tooltip is clipped by overflow:hidden

This is one of the most common tooltip bugs. The card needs rounded corners or image cropping, so it uses overflow:hidden. But the tooltip also lives inside that card, so the parent cuts it off.

Broken code

Parent clips tooltip
.card {
  position: relative;
  overflow: hidden;
}

.tooltip {
  position: absolute;
  bottom: 100%;
  z-index: 20;
}

Broken visual result

Tooltip gets cut off
Product card

The tooltip is inside a parent that clips anything outside the card.

Info This tooltip needs to escape the card, but overflow cuts it.
A higher z-index cannot fix clipping caused by parent overflow.

Correct code

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

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

Fixed visual result

Tooltip can escape
Product card

The tooltip can float outside the card because the parent no longer clips it.

Info This tooltip can now appear above the card.
If the component must crop images, put the cropped image in its own wrapper instead of clipping the whole card.
Error 2

The tooltip has a lower z-index than nearby content

If the tooltip is not clipped but still appears behind another card, header, image, or panel, the problem is layer order. The tooltip needs to be above the nearby interactive content.

Broken code

Low tooltip layer
.tooltip {
  position: absolute;
  z-index: 2;
}

.feature-card {
  position: relative;
  z-index: 10;
}

Broken visual result

Another element paints above it
Pricing option

The tooltip is visible, but another content layer overlaps it.

Info Low z-index tooltip hidden by a card.
Feature card This layer is above the tooltip.
The tooltip is not clipped. It is simply behind a higher layer.

Correct code

Tooltip layer wins
.tooltip {
  position: absolute;
  z-index: 100;
}

.feature-card {
  position: relative;
  z-index: 1;
}

Fixed visual result

Tooltip above nearby content
Pricing option

The tooltip has a deliberate layer above nearby cards.

Info Tooltip layer is now above the card.
Feature card The card no longer covers the tooltip.
Use a controlled z-index scale instead of guessing random numbers.
Error 3

A transformed parent creates a stacking context trap

A tooltip can have z-index:9999 and still lose if it is inside a parent stacking context. Common triggers include transform, filter, opacity, isolation, and positioned parents with z-index.

Broken code

Tooltip trapped
.card {
  transform: translateZ(0);
  z-index: 1;
}

.card .tooltip {
  position: absolute;
  z-index: 9999;
}

Broken visual result

Huge z-index still loses
Transformed card

The tooltip is inside a lower stacking context.

Info Even z-index 9999 cannot escape this parent.
Page layer
z-index only competes inside the stacking context where the element lives.

Correct code

Move tooltip to safe layer
<body>
  <main class="page">...</main>
  <div class="tooltip-layer">...</div>
</body>

Fixed visual result

Tooltip escapes the trap
Transformed card

The component can stay transformed.

Info
Page layer
Tooltip is rendered in a safer page-level layer.
For complex UI, render floating elements in a dedicated layer outside transformed components.
Error 4

The tooltip is positioned relative to the wrong parent

position:absolute uses the nearest positioned ancestor. If the trigger is inside one element but the tooltip is positioned relative to another, the tooltip can appear in the wrong place and hide behind unrelated content.

Broken code

No local anchor
.tooltip-wrap {
  /* missing position: relative */
}

.tooltip {
  position: absolute;
  bottom: 100%;
  left: 0;
}

Broken visual result

Tooltip floats from wrong place
Tooltip anchored to the wrong ancestor.
Settings row

The trigger is here, but the tooltip is not anchored locally.

Info
Other content The tooltip can collide with this.
The tooltip may look hidden because it is not positioned where you think it is.

Correct code

Local tooltip anchor
.tooltip-wrap {
  position: relative;
  display: inline-flex;
}

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

Fixed visual result

Tooltip anchored correctly
Settings row

The tooltip is positioned relative to the trigger area.

Info Tooltip is anchored to the right local parent.
Other content No longer fighting the tooltip.
Use a local wrapper for simple tooltips and a page-level layer for complex floating UI.
Premium pattern

A production-minded tooltip layer pattern

A stronger tooltip system separates normal layout from floating UI. Simple tooltips can use a local relative wrapper, but complex tooltips should use a dedicated high-level layer so cards, grids, overflow, and transforms do not trap them.

Premium code

Safe tooltip system
:root {
  --layer-tooltip: 1000;
}

.tooltip-anchor {
  position: relative;
  display: inline-flex;
}

.tooltip {
  position: absolute;
  left: 50%;
  bottom: calc(100% + 10px);
  z-index: var(--layer-tooltip);
  transform: translateX(-50%);
  max-width: min(260px, calc(100vw - 32px));
}

.card-media {
  overflow: hidden;
}

.card-body {
  overflow: visible;
}
/* For complex apps */
.tooltip-layer {
  position: fixed;
  inset: 0;
  z-index: var(--layer-tooltip);
  pointer-events: none;
}

.tooltip-layer .tooltip {
  position: absolute;
  pointer-events: auto;
}

Premium visual result

Floating layer, predictable result
Premium card

The card layout stays clean, and the tooltip has a predictable layer.

Info
Clean tooltip It floats above cards, grids, headers, and nearby sections.
Premium tooltip CSS does not depend on luck. It uses a clear anchor, safe overflow, and a controlled layer.

Fast practical rule

If a tooltip is hidden behind other elements, do not only increase z-index. First check whether the parent is clipping the tooltip with overflow:hidden. Then check stacking context, positioned ancestors, and whether the tooltip should live in a higher page-level layer.

Debug checklist

  • Inspect the tooltip and confirm it has a real position, usually position:absolute or position:fixed.
  • Check the parent container for overflow:hidden, overflow:auto, or overflow:clip.
  • Temporarily set the parent to overflow:visible to see if clipping is the cause.
  • Compare the tooltip z-index with nearby cards, headers, overlays, and dropdowns.
  • Look for stacking context creators like transform, filter, opacity, isolation, and positioned parents.
  • Make sure the tooltip is positioned relative to the intended wrapper.
  • Avoid placing app-level floating UI inside cards, sliders, or overflow-heavy layout wrappers.
  • Use a simple layer scale for tooltip, dropdown, header, modal, and overlay values.
Best first move Toggle parent overflow in DevTools. If the tooltip appears, you found the clipping parent.
Most common cause A card uses overflow:hidden for rounded corners and accidentally clips the tooltip.
Most sneaky cause A transformed parent traps the tooltip in a lower stacking context.
Better mindset Tooltips are floating UI. They should not be trapped by normal content layout.

Final takeaway

A tooltip hidden behind other elements is usually a layer and containment problem, not a text problem. The tooltip may be clipped by overflow, trapped in a stacking context, placed under another z-index layer, or positioned relative to the wrong parent.

Start with overflow, then inspect stacking context, then fix the tooltip’s layer strategy. For simple UI, a local relative wrapper can work. For complex UI, a dedicated tooltip layer is safer and easier to debug.

Want more fixes like this?

Browse more z-index, tooltip, overlay, and CSS debugging guides in the FrontFixer library.

Why Is My Modal Behind the Overlay?

Modal behind overlay problems usually happen when the overlay has a higher z-index than the modal, the modal is trapped inside a stacking context, or the modal and overlay are placed in the wrong HTML structure.

Modal z-index Fix

Why is my modal behind the overlay?

A modal behind overlay bug is one of the most confusing CSS problems because the modal exists, the overlay exists, and the code looks almost right. But visually, the dark overlay sits above the modal, the popup looks faded, or the modal cannot be clicked. The real issue is usually layer order: z-index, stacking context, position, transform, or where the modal is placed in the HTML.

  • Modal z-index
  • Overlay layer
  • Stacking context
  • Click blocking

What the bug looks like

The modal appears dim, sits under the dark background, cannot be clicked, or looks like it opens behind the page.

Why it happens

The overlay and modal are not in the right stacking order, or the modal is trapped inside a lower stacking context.

What usually fixes it

Put the overlay and modal in one predictable layer system, then make the modal layer higher than the overlay.

Error 1

The overlay has a higher z-index than the modal

This is the simplest version of the bug. The overlay is placed above the page, but the modal is not placed above the overlay. The result is a popup that looks hidden, darkened, or unclickable.

Broken code

Overlay wins
.overlay {
  position: fixed;
  inset: 0;
  z-index: 1000;
}

.modal {
  position: fixed;
  z-index: 50;
}

Broken visual result

Modal is under overlay
Page content
behind Modal

The popup is lower than the overlay layer.

The modal exists, but the overlay paints above it and steals the visual focus.

Correct code

Modal wins
.overlay {
  position: fixed;
  inset: 0;
  z-index: 1000;
}

.modal {
  position: fixed;
  z-index: 1001;
}

Fixed visual result

Modal above overlay
Page content
above Modal

The popup is now above the overlay layer.

The modal layer must be higher than the overlay layer.
Error 2

The modal is trapped inside a stacking context

A modal can have a huge z-index and still lose if it is inside a parent stacking context. A transformed parent, filtered parent, or positioned parent with its own z-index can trap the modal below the page overlay.

Broken code

Trapped modal
.card {
  transform: translateZ(0);
  z-index: 1;
}

.card .modal {
  position: fixed;
  z-index: 9999;
}

Broken visual result

Huge z-index still loses
Transformed parent
trapped Modal

The modal is inside a lower parent context.

A huge z-index cannot escape a parent stacking context.

Correct code

Page-level modal
<body>
  <main class="page">...</main>

  <div class="overlay"></div>
  <div class="modal">...</div>
</body>

Fixed visual result

Modal escaped the trap
Page card
page level Modal

The modal is a sibling of the overlay at page level.

Place app-level overlays and modals near the end of the body or in a portal/root layer.
Error 3

The modal has z-index, but no useful positioning

Developers often add z-index to a modal and expect it to jump above everything. But if the element is not positioned or not participating in a stacking order that accepts z-index, the value may not solve the layer problem.

Broken code

z-index without position
.overlay {
  position: fixed;
  inset: 0;
  z-index: 20;
}

.modal {
  z-index: 100;
}

Broken visual result

Layer rule incomplete
Page content
incomplete Modal

The modal layer is not defined clearly.

z-index alone is not a complete modal positioning system.

Correct code

Positioned modal layer
.overlay {
  position: fixed;
  inset: 0;
  z-index: 20;
}

.modal {
  position: fixed;
  inset: auto;
  z-index: 30;
}

Fixed visual result

Position and layer agree
Page content
defined Modal

The modal is positioned and layered above the overlay.

For modals, define both placement and layer order explicitly.
Error 4

The HTML order makes the overlay cover the modal

When two positioned elements are in the same stacking level, later elements can paint above earlier elements. If the overlay is inserted after the modal and both use similar z-index values, the overlay may cover the modal.

Broken code

Overlay after modal
<div class="modal">...</div>
<div class="overlay"></div>

Broken visual result

DOM order fights layer order
Page content
covered Modal

The overlay is inserted after this layer.

When layers are not explicit, DOM order can make the overlay paint above the modal.

Correct code

Explicit layer order
<div class="overlay"></div>
<div class="modal">...</div>

Fixed visual result

Overlay below modal
Page content
top layer Modal

The modal is inserted and layered above the overlay.

Use clear z-index values and sensible HTML order for overlay systems.
Premium pattern

A production-minded modal layer pattern

A reliable modal system uses named layer values, keeps modal and overlay close together in the DOM, and avoids placing modals inside transformed cards, sliders, headers, or small layout wrappers.

Premium code

Predictable modal stack
<div class="modal-root">
  <div class="modal-overlay"></div>

  <section class="modal-dialog" role="dialog" aria-modal="true">
    ...
  </section>
</div>
:root {
  --layer-overlay: 1000;
  --layer-modal: 1010;
}

.modal-overlay {
  position: fixed;
  inset: 0;
  z-index: var(--layer-overlay);
  background: rgba(15, 23, 42, .64);
}

.modal-dialog {
  position: fixed;
  left: 50%;
  top: 50%;
  z-index: var(--layer-modal);
  transform: translate(-50%, -50%);
  width: min(100% - 32px, 480px);
}

Premium visual result

Modal system, not z-index guessing
Page content
clean layer Modal dialog

The overlay and dialog have predictable, named layers.

Premium modal CSS avoids random z-index numbers and makes the layer order obvious.

Fast practical rule

If your modal is behind the overlay, compare the overlay layer and the modal layer first. Then inspect the modal’s parents for stacking context traps like transform, opacity, filter, isolation, and positioned wrappers.

Debug checklist

  • Inspect the overlay and modal in DevTools and compare their computed z-index values.
  • Make sure both overlay and modal have a real position, usually position:fixed.
  • Keep the modal z-index higher than the overlay z-index.
  • Check whether the modal is inside a transformed, filtered, or positioned parent.
  • Move app-level modals near the end of the document or into a dedicated modal root.
  • Avoid random values like z-index:999999; use a small layer scale instead.
  • Check whether the overlay is stealing clicks with pointer-events.
  • Verify that the modal is not inside a header, slider, card, or overflow-hidden wrapper.
Best first move Temporarily lower the overlay z-index. If the modal appears, the issue is layer order.
Most common cause The overlay has a higher z-index than the modal.
Most sneaky cause A parent with transform traps the modal inside a lower stacking context.
Better mindset A modal should be a page-level layer, not a child of whatever section opened it.

Final takeaway

A modal behind overlay problem is usually not fixed by throwing a bigger z-index at the modal. The real fix is to understand which stacking context the modal belongs to and whether the overlay is above it.

Place the overlay and modal in a predictable page-level layer, give the overlay a lower layer than the modal, and avoid trapping the modal inside transformed or overflow-heavy parents.

Want more fixes like this?

Browse more z-index, overlay, and CSS debugging guides in the FrontFixer library.

Why Is My Sticky Header Not Staying on Top?

Sticky header not staying on top problems usually happen when the header is missing a top value, trapped inside the wrong scroll container, placed behind content by z-index, or affected by overflow and stacking context rules.

Sticky Header Fix

Why is my sticky header not staying on top?

A sticky header can work for a few pixels, then disappear. It can stick inside the wrong parent, slide behind a hero section, or stop staying on top when another element creates a new stacking context. The fix is not just “add z-index.” You need to check the sticky offset, parent overflow, scroll container, and stacking order together.

  • position sticky
  • z-index
  • overflow hidden
  • stacking context

What the bug looks like

The header scrolls away, sticks only inside one section, sits behind content, or stops being clickable on mobile.

Why it happens

Sticky behavior depends on the nearest scroll container, the sticky offset, and the stacking context around the header.

What usually fixes it

Put the header high in the HTML, add a real top value, avoid trapping parent overflow, and use a deliberate z-index.

Error 1

position:sticky is missing the sticky offset

position:sticky does not mean “always stay at the top.” It means the element behaves normally until it reaches a specified offset. Without top:0, the browser may have no useful sticky boundary.

Broken code

Missing top value
.site-header {
  position: sticky;
  z-index: 10;
}

Broken visual result

Header scrolls away
not sticking
Brand
Hero section
Content keeps scrolling
The header has sticky positioning, but no clear top point where it should stick.

Correct code

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

Fixed visual result

Header knows where to stick
Brand
Hero section
Content scrolls under the header
top:0 tells the browser the exact point where the header should become sticky.
Error 2

A parent with overflow is trapping the sticky header

Sticky elements stick relative to their nearest scrolling ancestor. If the header is inside a wrapper with overflow:hidden, overflow:auto, or a short height, the header may only stick inside that wrapper instead of the page.

Broken code

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

.site-header {
  position: sticky;
  top: 0;
}

Broken visual result

Sticky is trapped
parent overflow
Brand
Wrapper area
The header cannot stick beyond this parent
The sticky header is not broken. It is obeying the wrong container.

Correct code

Header outside overflow wrapper
.site-header {
  position: sticky;
  top: 0;
  z-index: 100;
}

.page-shell {
  overflow: visible;
}

Fixed visual result

Sticky follows the page
Brand
Normal page content
No overflow trap
Keep the sticky header outside unnecessary overflow wrappers when it must stick for the whole page.
Error 3

The header is sticky, but it is behind other content

A header can stay at the top and still look broken if a hero, card, dropdown, or transformed section paints above it. In that case, the issue is stacking order, not sticky behavior.

Broken code

Low z-index
.site-header {
  position: sticky;
  top: 0;
  z-index: 1;
}

.hero-card {
  position: relative;
  z-index: 10;
}

Broken visual result

Content covers header
behind content
Brand
Hero card

This card paints above the sticky header because its z-index wins.

More page content
The sticky header is there, but another layer is visually covering it.

Correct code

Deliberate header layer
.site-header {
  position: sticky;
  top: 0;
  z-index: 1000;
}

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

Fixed visual result

Header stays above content
above content
Brand
Hero card

The content keeps its layer, but the header has the higher page-level layer.

More page content
Use a consistent z-index scale for headers, menus, overlays, and content cards.
Error 4

The sticky header is inside the wrong HTML structure

A site-wide sticky header should usually live near the top of the page structure, not inside a hero section, card, slider, or small wrapper. If its parent ends, the sticky behavior ends with it.

Broken code

Header nested too deep
<section class="hero">
  <header class="site-header">...</header>
  <div class="hero-content">...</div>
</section>

<main>...</main>

Broken visual result

Sticky ends with section
wrong parent
Brand
Hero wrapper
Main content after hero
The header cannot stay sticky for the full page if it belongs to a short section.

Correct code

Header at page level
<header class="site-header">...</header>

<main>
  <section class="hero">...</section>
  <section class="content">...</section>
</main>

Fixed visual result

Header controls the page
Brand
Hero section
Content section
A page-level header has a page-level sticky boundary.
Premium pattern

A production-minded sticky header pattern

A reliable sticky header pattern uses a page-level header, a clear sticky offset, a deliberate z-index layer, and avoids placing the header inside wrappers that create scroll or stacking traps.

Premium code

Sticky header system
<header class="site-header">
  <a class="logo" href="/">Brand</a>
  <nav class="main-nav">...</nav>
</header>

<main class="site-main">
  ...
</main>
:root {
  --header-layer: 1000;
}

.site-header {
  position: sticky;
  top: 0;
  z-index: var(--header-layer);
  background: rgba(255,255,255,.96);
  border-bottom: 1px solid #e5e7eb;
}

.site-main {
  min-width: 0;
}

html {
  scroll-padding-top: 80px;
}

Premium visual result

Predictable sticky layer
Brand
Hero section
Content section
Premium sticky headers are not magical. They are page-level elements with clean parents and predictable layers.

Fast practical rule

If a sticky header is not staying on top, do not start by throwing bigger z-index values at it. First confirm top:0, then check parent overflow, then check whether another element created a stacking context above the header.

Debug checklist

  • Check that the header has position:sticky and a real offset like top:0.
  • Inspect every parent of the header for overflow:hidden, overflow:auto, or overflow:scroll.
  • Move the header outside short wrappers, hero sections, sliders, and cards when it should stick for the whole page.
  • Give the header a deliberate page-level z-index, such as z-index:1000.
  • Check whether another element has a higher z-index than the header.
  • Look for stacking context creators like transform, filter, opacity, isolation, or positioned parents.
  • Test mobile breakpoints to make sure the header is not switched back to position:static.
  • If anchor links hide under the header, add scroll-padding-top or scroll-margin-top.
Best first moveAdd or confirm top:0. Sticky needs an offset to know when to stick.
Most common causeA parent wrapper with overflow changes the sticky boundary.
Most misleading causeThe header is sticky, but content paints above it because of z-index or stacking context.
Better mindsetSticky headers need structure, not random z-index numbers.

Final takeaway

A sticky header not staying on top is usually not one single CSS mistake. It is usually a combination of sticky offset, parent overflow, z-index, stacking context, and HTML structure.

Start with top:0, then inspect the parent containers, then fix the stacking order. Once the header is a clean page-level element with a deliberate layer, it becomes predictable on desktop and mobile.

Want more fixes like this?

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

Why Is My Dropdown Getting Cut Off?

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.

  • 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.

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.