The stacking context — z-index gotchas explained

The z-index: 9999 element loses here because z-index values are only ever compared within the same stacking context — and the first outer div (with z-index: 1) creates its own stacking context, trapping the 9999 inside it. Once trapped, that 9999 is compared against the outer elements' z-indices (1 vs 2), not against anything inside the second outer div at all — the inner 9999 never gets a chance to compete globally, because stacking contexts nest like sealed boxes, not a single flat list.

This is the real, common surprise: stacking contexts aren't only created by position + z-index — opacity less than 1, any transform, filter, will-change, and several other properties each independently create a new one, entirely regardless of whether z-index is even set. This is exactly why adding an animation (transform, commonly) to an element can suddenly break its stacking relationship with a dropdown or tooltip elsewhere on the page — a change that looks completely unrelated to layering can silently create a new sealed box that traps or excludes other elements' z-index comparisons.

Because the actual scope a z-index competes within is determined by the nearest ancestor stacking context, the fix for "it's not working even at 99999" is almost never "raise the number further" — a trapped z-index stays trapped regardless of magnitude. The real fix is finding which ancestor is creating the unwanted boundary and either removing the property causing it, or moving the z-index competition up to that same level instead.