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.
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
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
Once the parent is no longer clipping the menu, the dropdown can render outside the trigger box.
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
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
The dropdown belongs to a higher positioned context, so it can sit above the next section.
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.
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.
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
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, andoverflow:scroll. - Temporarily set suspicious parents to
overflow:visibleto 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%, andleft:0. - Inspect parents for stacking-context creators like
transform,filter,opacity,isolation, andwill-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.
z-index:999999 while a parent is still physically clipping the menu.
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.