CSS Stacking Context Checker

What is a stacking context?

A stacking context is a group of elements that are painted together as a unit. Inside one, z-index decides the order; outside it, the whole group is placed as a single item and its children cannot escape. That is the sentence behind almost every z-index bug: a child at 999999 is not competing with the rest of the page, only with its siblings inside the same context.

The second half of the confusion is that z-index often does nothing at all. CSS 2.2 gives the property an Applies to line reading positioned elements, so on a static element it is not a weak declaration — it is not applied. That is why raising the number never helps.

This stacking context checker answers both questions from the CSS you paste, and names the specification behind each answer, because the rules are spread across seven different documents and no single one lists them all.

How to use it

1. Paste the element's declarations. One per line or separated by semicolons. The three sample buttons cover the commonest cases: a z-index that is silently ignored, an opacity that creates a context nobody expects, and a fixed modal that traps everything inside it.
2. Tell it what the parent is. Block, flex or grid. This matters more than it sounds — the same z-index is inert in a block parent and works in a flex or grid one, and that single control is the difference between the two answers.
3. Read the two verdicts, then the reasons. The first says whether z-index applies. The second says whether this element traps its descendants, with each cause listed beside the specification that defines it.

The flex and grid exception nearly everyone misses

The rule most people carry around is that z-index only works on positioned elements. It is very nearly right, and the exception is written into two specifications in identical words. CSS Flexbox says that for flex items, z-index values other than auto create a stacking context even if position is static. CSS Grid says exactly the same sentence for grid items.

So the same declaration behaves in two different ways depending on the parent. Inside a normal block container, a static element with z-index: 999999 is inert and creates no stacking context. Move that element into a flex container without changing one character of its own CSS, and the z-index now applies and creates a context. This tool has a control for the parent for that reason alone — it is the only input that changes the answer without changing the CSS.

There is a matching surprise on the other side. With z-index left at auto, relative and absolute positioning create no stacking context, while fixed and sticky always do. The CSS Positioned Layout specification states it plainly: fixed and sticky positioned boxes nonetheless form a stacking context. So half the position values behave one way and half the other, on the value you never set deliberately.

The one that is invisible: opacity

Of the seventeen causes this page lists, opacity is the one worth memorising, because nothing on screen hints at it. An element with opacity: 0.999 looks exactly like one with opacity: 1 — you cannot tell them apart at any zoom level — and yet the first creates a stacking context and the second does not. Every descendant is suddenly trapped, and a dropdown that used to sit above the header now sits behind it.

The same trap comes in several other shapes. A transform of any kind, a filter, a backdrop-filter, a clip-path, a mask, a mix-blend-mode other than normal, isolation: isolate, contain with paint or layout, and will-change naming any of those properties all create a context. Several of them are added for performance or for a hover effect, by somebody who was not thinking about painting order at all.

That is why the fix for a stuck z-index is almost never a bigger number. It is to find the ancestor doing the trapping and decide whether it should be. The tool reports every cause it finds rather than the first, because an element frequently has three or four at once and removing only one changes nothing.

Honest limitations

This checks one element at a time. A stacking context is a property of an element, but the bug is a property of a tree — to know whether your modal is trapped you have to look at its ancestors, one by one, and the tool cannot see them from a single block of CSS. What it gives you is the per-element answer to take up the tree.

It reads declarations literally and does not resolve the cascade, custom properties, shorthands or media queries. If your opacity comes from a class you did not paste, or from a var() defined elsewhere, this cannot know. Paste the computed styles from your browser's inspector if you want certainty.

The list of causes is the set defined across the specifications cited beside each row, and it is not frozen — the CSS specifications add to it. contain and will-change were both recent additions, and there is no single normative document that lists every cause, which is precisely why each row here carries its own citation instead of pointing at one page.

Specification names stay in English on every language version of this page, because they are document identifiers rather than prose. A reader looking one up needs the string the standards body actually published.

Why is it free?

It is text analysis, and it runs in your browser. There is no server involved, so there is nothing to bill for and no account to create.

Nothing is uploaded and nothing is stored. Reload the page and it has forgotten your CSS.