CSS stacking contexts explain why z-index: 99999 sometimes loses to z-index: 2. The browser does not compare z-index values globally. It compares them only within the same stacking context, which acts as a self-contained layer. A child element trapped inside a parent stacking context can never visually escape it, no matter how high its z-index is set.
Properties like opacity, transform, filter, and position with a non-auto z-index all create new stacking contexts. This happens not for visual reasons but for rendering performance: the browser isolates these elements into separate compositor layers to avoid recalculating the entire page on every change. That side effect is the source of most z-index bugs developers spend hours chasing. MDN maintains the full list of triggering properties, and it is longer than most developers expect.
The article uses a concrete modal scenario to show exactly how a fixed-position overlay with z-index: 1 can disappear behind other content when its parent already sits inside a competing stacking context. The real value here is not just the diagnosis but the practical approaches to resolving these conflicts without rewriting your entire CSS. If you have ever blamed z-index for behaving irrationally, the problem was the folder, not the paper.
[READ ORIGINAL →]