Before anything else, one check that costs five seconds: z-index does nothing at all on an element whose position is static. That is the default. If the property is not being read, no value of it is going to help.

The exception is a flex or grid child, where z-index applies without positioning. It is the one place the property works on a static element, and it is a pleasant surprise exactly once.

Past that, raising the number stops helping, and it stops helping abruptly rather than gradually. The reason is that z-index does not sort an element against the page. It sorts it against its siblings, inside a box called a stacking context.

The stacking context is the whole answer

A stacking context is a self-contained painting order. Everything inside one paints together, as a unit, at whatever position its root occupies in the parent context. Nothing inside can paint above something outside it.

Which produces the rule that explains almost every one of these bugs: a child of a context with z-index: 1 sits below a sibling of that context with z-index: 2 — at 9999, at 2147483647, at any number you can type.

the tooltip never wins, and the number is irrelevant

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

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

/* .tooltip paints inside .card, so it paints under .overlay.
   The only number that matters here is the 1. */

The same tooltip at z-index: 9999, twice. The only thing changing is opacity on its parent - and opacity below 1 opens a stacking context, which puts the tooltip under an overlay it used to sit above. — runs on the page itself.

So the element you are editing is rarely the one deciding. The question is which ancestor opened a context, and where that ancestor sits among its own siblings.

It is worth being precise about what a context does to the numbers inside it, because the mental model people carry is usually a bigger number wins rather than the true one, which is closer to a version scheme. 1.9999 is still less than 2. The ancestor is the integer part.

What creates one is a longer list than anybody remembers

The familiar case is a positioned element with a z-index other than auto. The rest is where the surprises live:

opacity

Any value below 1. A hover state at 0.98 opens a context for the whole subtree.

transform

Any value other than none — including translateZ(0), added for the compositor by someone not thinking about paint order at all.

filter, backdrop-filter

Any value. A blur behind a sticky header is the usual arrival route.

mix-blend-mode

Anything other than normal.

isolation: isolate

The only one on this list whose entire purpose is to do it, and therefore the only one that is never a surprise.

contain

paint, layout, strict or content.

will-change

Naming any property above. A hint about performance that changes correctness.

position: fixed

On its own, with no z-index involved at all.

This is why the bug so often arrives with a commit that has nothing to do with layering. A card gets a hover opacity, a section gets a transform, and a dropdown three levels down that worked yesterday is trapped. Nothing about the dropdown changed.

The move that actually finds it

Do not start at the element. Start above it and work down:

1. Walk from the trapped element up to the root, and at every ancestor ask the one question: does this open a stacking context?
2. The first ancestor that does is your ceiling. Nothing below it can ever paint above something outside it.
3. Find where that ceiling sits among its own siblings. That comparison — not the one you were editing — is the one deciding.
4. Fix it there: raise the ceiling, or move the element out from under it, and put the child back to a number a person can read.

Doing that by hand means reading computed styles for eight properties on every ancestor, which is precisely why it turns into raising the number instead. It is worth doing properly once, because the answer is nearly always a single ancestor with a property nobody associates with layering.

The four fixes, worst to best

Raise the number

Works only when the two elements are already in the same context, which is the case you did not have. It is the fix that produced 9999 in the first place - each round of it raises the ceiling nobody found.

Raise the ancestor

Correct, and usually a one-line change: put the z-index on the ceiling instead of on the child. The risk is that the ceiling now beats things it should not, so it moves the problem up a level rather than removing it.

Move the element out

Render the overlay as a sibling of the ceiling rather than a descendant. In a component framework that means a portal, and the reason portals exist is precisely this - not styling, paint order.

Use the top layer

For anything modal, this is the answer, and it is the only one that cannot regress. See below.

There is a fifth thing people try - position: fixed on the trapped element - and it is worth naming because it seems to work. A fixed element escapes scrolling ancestors, not stacking contexts. If any ancestor has a transform, filter or will-change, the fixed element is positioned against that ancestor instead of the viewport, and the bug becomes two bugs.

isolation: isolate, and the one time you want more of this

Everything above treats a stacking context as an accident. isolation: isolate is the property that creates one on purpose, and it is the right tool in one specific situation: a component whose internal layering must not leak into the page it is dropped into.

a component that cannot fight with the page around it

.widget {
  isolation: isolate;
}

/* Everything inside .widget now sorts among itself.
   The page sorts .widget as one thing.
   Nothing inside can reach past it, in either direction. */

That is the same mechanism causing every bug in this article, aimed deliberately. A stacking context is not a hazard; an accidental one is. The difference is whether you knew you were opening it.

The top layer ignores all of it

A <dialog> opened with showModal(), an element with the popover attribute, and anything in fullscreen do not participate in this system at all. They paint in the top layer: above every stacking context on the page, in the order they were opened.

no z-index anywhere, and nothing can cover it

<div popover id="menu">…</div>
<button popovertarget="menu">Open</button>

No z-index competes with the top layer and none is needed on it. Which makes it the real fix for the case that produces 9999 in the first place — a modal, a tooltip, a menu that has to escape whatever it is nested in. Not a bigger number. A different layer.

Sideways scroll is one of the few layout bugs with a single cause. Something is wider than the viewport, or starts far enough right that its edge lands outside it. There is no cascade to reason about and no specificity to lose to. There is one element, and the work is finding it.

It is also the bug most often closed without being found, because hiding it takes one line and looks identical in the screenshot.

The handful of things that actually do it

100vw

On a desktop browser with a classic scrollbar, 100vw is the viewport including the scrollbar; the content box you are comparing it against is not. A full-bleed section overflows by around fifteen pixels — enough to scroll, small enough to read as a rendering fault.

min-width: auto

The default on flex and grid children, and it means do not shrink below your content. A long word, a wide table or an unbroken URL in a grid cell will push the whole track. Responsible for more of these than everything else here combined.

Fixed pixel widths

A width: 480px card in a 390px viewport. Obvious in review, invisible on the desktop it was written on.

Negative margins

A full-bleed trick pulling content out past the right edge, usually correct on one breakpoint and not the others.

Absolute positioning

right: -40px on a decorative shape. The element is out of flow, but not out of the scroll area.

Unbreakable strings

A URL, a hash, a wallet address, a base64 blob. No spaces means no wrap opportunity, unless overflow-wrap: anywhere says otherwise.

Three rows in a frame. Two are sized to the content box; the middle one is sized to 100vw, which on a desktop browser includes the scrollbar the content box does not get. Fifteen pixels, and the page scrolls. — runs on the page itself.

Worth knowing what does not do it: box-shadow and outline paint outside the box without contributing to scroll width. transform: translateX does contribute, even though the layout position has not moved.

Why the outline trick misleads

the advice everybody gives

* { outline: 1px solid red; }

It works often enough to stay in circulation, and it is wrong in a specific way: it marks every element, so the offender and its dozen innocent descendants all appear to stick out together. You end up staring at the deepest one — a <span> inside the thing that is actually too wide — because it is the one whose red box is easiest to see.

It also cannot see anything already clipped by an ancestor with overflow: hidden set for a legitimate reason, which is exactly where these hide.

Measure edges instead

The reliable test is arithmetic, not colour. Compare every element's right edge against the document width, then take the shallowest element that fails:

the whole diagnosis, in five lines

const limit = document.documentElement.clientWidth;

[...document.querySelectorAll('*')]
  .filter((el) => el.getBoundingClientRect().right > limit)
  .slice(0, 5);

// The first result is the cause.
// Everything after it is a passenger inside the cause.

The same pass catches the left side, which people forget exists. An element at a negative offset does not always produce scroll — a browser does not scroll into inline-start overflow in a left-to-right document — but it does in a right-to-left one. Which is how this ships broken in Arabic and Hebrew after passing every check in English.

The two fixes for the two commonest causes

Once the element is identified, the repair is nearly always one of two lines. Neither is clever, and both are worth knowing by heart.

full bleed without the scrollbar arithmetic

.bleed {
  width: 100dvw;
  margin-inline: calc(50% - 50dvw);
}

/* Or skip the unit question entirely: */
.bleed-grid {
  grid-column: 1 / -1;
}

letting a flex or grid child actually shrink

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

.track pre,
.track code {
  overflow-wrap: anywhere;
}

/* min-width: auto is the default and it means
   "never shrink below my content". A table, a long
   URL or a wide <pre> will push the whole track. */

min-width: 0 on flex and grid children is the single highest-value line in responsive CSS, and it is invisible until the day a long word arrives. Some teams set it globally on grid and flex children and never see this class of bug again.

Catching it before a person does

This bug has an unusual property among layout bugs: it is trivially detectable in CI. It is one comparison of two numbers, it needs no screenshots and no visual diffing, and it fails deterministically.

the assertion, at three widths

for (const width of [320, 768, 1280]) {
  await page.setViewportSize({ width, height: 900 });
  const scrolls = await page.evaluate(
    () => document.documentElement.scrollWidth >
          document.documentElement.clientWidth,
  );
  expect(scrolls, `scrolls sideways at ${width}px`).toBe(false);
}

320 is the width WCAG asks a page to reflow to, so that row is a conformance check as well as a layout one. Adding those three lines is usually the last time anybody thinks about horizontal overflow in that codebase.

When hiding it is the correct answer

Sometimes it genuinely is: a decorative shape deliberately drawn past the edge, a carousel whose track is meant to be wider than its frame. In both cases the clip belongs on that element or its immediate container — never on body or html.

The reason is not tidiness. overflow on the scroll container is what makes position: sticky stop working, and the failure surfaces somewhere else entirely, weeks later, as a header that will not stick. A clip scoped to the thing being clipped costs nothing and takes nothing else down with it.

If you inherit a codebase with overflow-x: hidden on body, remove it before debugging anything sticky. You are not looking for a sticky bug. You are looking for the overflow it was hiding.