z-index

Why Is My Button Not Clickable?

by

Button not clickable bugs usually happen when the visible button and the real clickable layer are not the same thing. An invisible overlay, disabled state, pointer-events rule, or broken HTML structure can make a button look normal while clicks go nowhere.

Interaction Fix

Why is my button not clickable?

A button can look perfectly fine and still refuse to click. The color is right, the hover state may appear, the spacing looks clean, and the design seems finished. But the browser does not click what your eyes see. It clicks the topmost interactive layer under the pointer. If another element is covering the button, if pointer-events is wrong, if the button is disabled, or if the markup is not truly interactive, the UI can feel dead even though the visual design looks normal.

Browse All Fixes Explore HTML Fixes
  • Invisible overlays
  • Pointer-events bugs
  • Disabled states
  • Broken hit areas

What the bug looks like

The button is visible, styled correctly, and seems ready to work, but clicks do nothing, only part of the button responds, or the button works in one layout but not another.

Why it happens

The browser usually is not ignoring the button. Something in the stacking order, pointer behavior, disabled state, markup, or hit area is blocking the click.

What usually fixes it

Use DevTools to inspect the topmost layer under the cursor, then check pointer-events, disabled, semantic markup, and the real size of the clickable target.

Why a button can look clickable but still be dead

A button bug is often not a button-design bug. It is an interaction-layer bug. The visible button may be behind another layer, inside a disabled form state, covered by a pseudo-element, or visually larger than the actual clickable element.

This is why blindly changing colors, padding, or hover styles rarely fixes the problem. You need to find what element is actually receiving the click. The same idea appears in other FrontFixer layout bugs: with z-index problems, what appears visually on top may not be in the layer system you think; with dropdowns getting cut off, the issue may be a parent wrapper rather than the dropdown itself.

Error 1

An invisible overlay is stealing the click

This is the most common reason a button is not clickable even though it looks normal. A decorative layer, pseudo-element, full-card overlay, modal backdrop, or animation layer is placed above the button. The user thinks they are clicking the button, but the browser is clicking the invisible layer instead.

Broken code

Overlay wins 
.card {
  position: relative;
}

.card::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: 5;
}

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

Broken visual result

Click blocked
Save changes

The button is visible, but an invisible layer is sitting above it and receives the click first.

Correct code

Clicks pass through 
.card::before {
  content: "";
  position: absolute;
  inset: 0;
  z-index: 1;
  pointer-events: none;
}

.card .button {
  position: relative;
  z-index: 2;
}

Fixed visual result

Click reaches button
Save changes

The decorative layer no longer steals pointer events, and the real button is above it in the stacking order.

Error 2

pointer-events:none is on the wrong element

pointer-events:none can be useful on decorative layers, but it is dangerous on real interactive elements. If the button itself, or a parent wrapper, has pointer events disabled, the UI may render normally while ignoring clicks.

Broken code

Dead interaction 
.button {
  pointer-events: none;
}

Broken visual result

Looks active, ignores click
Checkout button pointer-events: none
Newsletter button parent blocks it
Card CTA no click target

The button can still look styled, but the browser is told not to treat it as a pointer target.

Correct code

Interactive target 
.button {
  pointer-events: auto;
}

.decorative-overlay {
  pointer-events: none;
}

Fixed visual result

Real button receives pointer
Checkout button clickable
Newsletter button clickable
Card CTA clickable

Pointer events should be disabled on decorative layers, not on the button users need to click.

Error 3

The button is disabled but still looks active

A disabled button is supposed to ignore clicks. The bug happens when the visual design does not make that disabled state obvious. Developers then spend time debugging JavaScript or CSS when the markup already says the button cannot be clicked.

Broken expectation

Markup says disabled 
<button class="button" disabled>
  Save changes
</button>

Broken visual result

Disabled state

Account settings

The button may look designed, but the HTML state blocks interaction.

disabled

If the button has disabled, it cannot be clicked until that state is removed.

Correct state

Active button 
<button type="button" class="button">
  Save changes
</button>

Fixed visual result

Enabled state

Account settings

The button is now semantically enabled and can receive clicks.

enabled

Good UI makes disabled and enabled states visually clear, so users and developers do not confuse them.

Error 4

The visual button is larger than the real clickable target

Sometimes the full visual shape looks like a button, but only a small text link inside it is actually clickable. This creates the frustrating “only part of my button works” bug. The visual hit area and the real interactive element must match.

Broken structure

Tiny real target 
<div class="button-look">
  <a href="/checkout">Checkout</a>
</div>

Broken visual result

Only a small area works
Big visual button
Real link
The visual button is large, but the actual clickable anchor is much smaller.

Users click the large visual area, but only the small nested link actually receives navigation.

Correct structure

Full target 
<a class="button" href="/checkout">
  Checkout
</a>

Fixed visual result

The full button is clickable
Full clickable button
The link itself owns the full visual shape, so the hit area matches what users see.

The clickable element should usually be the same element that creates the visual button shape.

Error 5

The HTML structure is invalid or fighting the browser

Button bugs can also come from invalid structure: buttons inside links, links inside buttons, clickable wrappers inside clickable wrappers, or custom components that use a <div> where a real <button> should be used.

Fragile markup

Nested interaction 
<a href="/pricing">
  <button>View pricing</button>
</a>

Why this is risky

Nesting interactive elements makes click behavior harder to predict and can create accessibility problems. The browser, screen readers, and keyboard navigation may not treat the UI the way you expect.

Cleaner markup

One interactive element 
<a class="button" href="/pricing">
  View pricing
</a>

<button type="button" class="button">
  Open modal
</button>

Better rule

Use a link when the action navigates somewhere. Use a button when the action changes something on the current page. Do not nest one interactive element inside another.

Fast practical rule

If your button is not clickable, do not start by rewriting the button style. First use DevTools to inspect what element is actually under the cursor. If the selected element is not the button, you have a layer or hit-area problem. If it is the button, check disabled, pointer-events, event listeners, and semantic markup.

How to debug the click target in DevTools

Open DevTools and use the element picker. Move the cursor over the button and watch which element gets highlighted. If an overlay, pseudo-element, wrapper, or backdrop is selected instead of the button, the browser is telling you exactly why the click does not reach the button.

Then temporarily disable suspicious CSS rules: z-index, position:absolute, inset:0, pointer-events, opacity, and overlay pseudo-elements. The goal is not to guess. The goal is to reveal the real click layer.

Quick temporary debug CSS

Find blockers 
* {
  outline: 1px solid rgba(255, 106, 61, .35);
}

.card::before,
.overlay,
.backdrop {
  outline: 3px solid red;
}

Safe CTA pattern

Navigation button 
<a class="button" href="/fixes/">
  Browse fixes
</a>
.button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-height: 44px;
  padding: 0 18px;
  border-radius: 999px;
  background: #ff6a3d;
  color: #fff;
  position: relative;
  z-index: 2;
}

Why this pattern is safer

The link owns the full button shape. The hit area matches the visual shape. The element is semantically correct for navigation, and the position plus z-index gives it a predictable place if decorative layers exist around it.

For actions that open a modal, submit a form, or change the current interface, use a real <button> instead.

Debug checklist

  • Use DevTools element picker and confirm the button is the element actually under the cursor.
  • Check for overlays, pseudo-elements, full-card links, modal backdrops, sticky bars, or wrappers covering the button.
  • Inspect ::before and ::after on parent containers.
  • Look for pointer-events:none on the button or any ancestor.
  • Check whether the button has the disabled attribute.
  • Confirm the visual hit area and the real clickable element are the same size.
  • Avoid nesting buttons inside links or links inside buttons.
  • Use <a> for navigation and <button> for in-page actions.
  • Test mobile separately, because overlays and menu layers often change across breakpoints.
  • Do not assume the CSS class is broken until you know what layer receives the click.
Best first move Inspect the exact element under the cursor before editing the button styles.
Most common false fix Raising the button z-index without checking whether the overlay should use pointer-events:none.
Most overlooked cause A pseudo-element covers the whole card and silently steals every click.
Better mindset A button not clickable bug is usually about hit testing, not just styling.

Related fixes that can help

If your button problem turns out to be structural, layered, or responsive, these FrontFixer guides are the next places to check.

Fix z-index not working If the button is behind another layer or the wrong element is sitting on top. Read this fix
Fix HTML structure problems If the clickable UI is built from invalid markup or the wrong semantic element. Read this fix
Why is my dropdown getting cut off? If the button belongs to a menu, dropdown, or layered component that is being clipped. Read this fix

Final takeaway

When a button is not clickable, the visible design is not enough evidence. The browser clicks the real topmost interactive layer, not the layer you intended users to click. That means invisible overlays, pseudo-elements, disabled states, pointer-event rules, and invalid markup can all make a normal-looking button feel broken.

Start by identifying the actual click target in DevTools. Then remove blockers, restore pointer events, fix disabled states, and make sure the visual button and the real interactive element are the same thing. Once you debug the interaction layer, button bugs become much easier to fix.

Want more fixes like this?

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

Browse All Fixes Explore HTML Fixes

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