> ## Content Index
> Fetch the complete content index at: https://debugly.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# Your CSS Header Is Sticky. Which Box Is It Sticking To?
- URL: https://debugly.dev/css-sticky-header-overflow-scrollport/
- Published: 2026-11-09T07:26:00.000Z
- Updated: 2026-11-09T07:26:00.000Z
- Description: A wrapper that hides horizontal overflow can make a sticky header scroll away. Check both computed axes to find which box owns the scrollport.
- Author: Rohit Bhadani
- Tags: CSS, Frontend, Debugging

The sticky header works until someone adds one innocent-looking rule to stop horizontal overflow. Now the page scrolls and the header leaves with it. Before changing `top` or `z-index`, inspect the wrapper’s computed `overflow-x` and `overflow-y`. `overflow-x: hidden` can turn the wrapper into the header’s nearest scroll container, even though the scrollbar you’re using belongs to the page.

*This is an AI-prepared, documentation-based explainer, not a personally reproduced incident. The examples are illustrative and were not run in a browser. See the* [*editorial policy*](https://debugly.dev/editorial-policy/)*.*

## The header is listening to the wrong box

Picture a report with a toolbar inside a wrapper that grows with the report. A wide chart sticks out to the right, so the wrapper gets `overflow-x: hidden`. The page still scrolls vertically, but the toolbar no longer pins to the top of the viewport. There’s no obvious new scrollbar to give the wrapper away.

The [CSS Overflow rules](https://www.w3.org/TR/css-overflow-3/?ref=debugly.dev#overflow-properties) explain the clue: when one axis is `hidden`, the other axis’s default `visible` computes to `auto`. And `hidden` still allows programmatic scrolling where there’s overflow. In the familiar nearest-scrollport model, [sticky positioning](https://www.w3.org/TR/css-position-3/?ref=debugly.dev#sticky-pos) uses that ancestor’s scrollport for its insets. The wrapper can be tall enough to fit its content and have no useful vertical scroll range. Scrolling the page then moves the entire wrapper, header included. A bigger `z-index` just gives the departing header a better seat.

## Find the wrapper without guessing

First verify that the header has `position: sticky` and a non-auto inset on the axis you’re testing, such as `top: 0` for a conventional vertical page. Then select the header in DevTools and walk upward, checking computed overflow on both axes. This illustrative snippet starts from `$0`, the selected element in browsers that expose that console shortcut:

```
for (let el = $0.parentElement; el; el = el.parentElement) {
  const css = getComputedStyle(el);
  console.log(el, css.overflowX, css.overflowY,
              el.scrollHeight - el.clientHeight);
}
```

Look for the first ordinary wrapper with `hidden`, `auto` or `scroll` and compare its vertical range with the box that actually moves when you scroll. A zero range is a clue, not proof: it doesn’t make a scroll container disappear, and root/body overflow has special viewport rules. Temporarily disable the suspected overflow declaration. If the header sticks again, you’ve isolated a cause without rewriting the layout. If it still doesn’t, inspect the containing block’s height and the header’s available travel. Sticky offsets are constrained by the containing block; a short parent can stop a sticky header even when the correct scrollport was chosen.

## Decide who should own the scrolling

If the wrapper only needs to crop decorative horizontal spill, try `overflow-x: clip; overflow-y: visible` on that ordinary wrapper. In the overflow spec, `clip` paired with `visible` does not make it a scroll container. Remove conflicting shorthand declarations and check the computed pair again; combining `clip` with a scrollable value on the other axis can change the result. Unlike `hidden`, `clip` also prevents programmatic scrolling in the clipped direction and doesn’t establish a formatting context by itself. If the old rule was also containing floats, consider `display: flow-root` where appropriate. Verify that keyboard focus and essential content can still be seen.

If the chart or table really needs horizontal scrolling, put that scrolling on a separate child that does not contain the page-sticky toolbar. If the whole report should scroll inside a panel, constrain the panel height and keep the toolbar inside it so it sticks within the panel instead. Those are different designs. Test the one you mean to ship by scrolling the actual owner, at a narrow and wide viewport, and tabbing through controls near the clipped edge.

The [CSS Working Group has discussed single-axis sticky behavior](https://www.w3.org/2026/03/11-css-minutes.html?ref=debugly.dev); a design discussion doesn’t establish support in your deployed browsers. Check the computed values and test your actual browser set. If the overflow rule was only hiding a row that should have shrunk in the first place, the [flexbox minimum size walkthrough](https://debugly.dev/css-flexbox-minimum-size-wrapper-overflow/) shows how to diagnose that sizing problem at its source.