CSS Position Sticky Not Working? Inspect the Parent First

You add position: sticky and top: 0 to a sidebar. Scroll the page. The sidebar leaves with everything else.

A higher z-index seems reasonable. Still gone. Now your prompt says “fix the sticky sidebar,” and the AI agent suggests position: fixed. The sidebar stays visible, but it’s no longer taking up space in the layout. Progress, technically. A new bug, practically.

For CSS position sticky not working, I’d inspect the parent chain before asking for another CSS rewrite. The useful evidence is usually outside the box you’re trying to stick.

CSS position sticky not working: check the offset, then the boundary

Sticky needs a non-auto inset on the axis you want it to follow. For vertical sticking in a typical horizontal writing mode, start with:

.sidebar {
  position: sticky;
  top: 1rem;
}

Then distinguish two boundaries: the scrollport supplies the sticking threshold, while the containing block limits how far the box can travel. They’re not necessarily the viewport and the immediate parent you expected. MDN’s position reference explains those constraints and the inset requirement.

For me, that’s the useful shift in the debugging question: “Which box is this sticking inside?” gives you something to inspect. “Why won’t sticky work?” gives you another round of guesses.

Find the ancestor that owns scrolling

An ancestor with overflow: hidden, auto, or scroll can establish the scroll container sticky uses, even when you’re scrolling the document instead. hidden is the sneaky one: there’s no scrollbar announcing the change.

It’s CSS saying, “Of course I’ll stick. To the box you forgot existed.”

In Chrome DevTools:

1. Inspect the sidebar and open Computed. Confirm position and top at the failing viewport width.
2. Select each ancestor in the Elements tree. Check both overflow-x and overflow-y.
3. Identify whether the document or an inner panel actually scrolls during reproduction.
4. Temporarily disable the suspicious overflow declaration in Styles, then repeat the same scroll.
5. Restore it and decide whether scrolling, clipping, or neither was intended there.

Chrome’s CSS features reference documents the distinction between matched rules in Styles and applied values in Computed. That’s why reading the stylesheet alone isn’t enough: a breakpoint or another rule may have changed the result.

For a long ancestor chain, this read-only Console snippet prints the relevant values. Replace .sidebar with your actual selector:

const target = document.querySelector('.sidebar');

if (!target) {
  throw new Error('No element matches .sidebar');
}

const ancestors = [];
for (let node = target.parentElement; node; node = node.parentElement) {
  const style = getComputedStyle(node);
  ancestors.push({
    element: node,
    overflowX: style.overflowX,
    overflowY: style.overflowY,
    clientHeight: node.clientHeight,
    scrollHeight: node.scrollHeight,
  });
}
console.table(ancestors);

This walks ordinary DOM parents, not across shadow roots or iframe documents. Inspect those boundaries separately when they’re involved. Also, scrollHeight > clientHeight tells you there’s excess content, not that this is the container the user is scrolling. Reproduce that part yourself.

Should you replace overflow hidden with clip?

Only if you want clipping without scrolling. overflow: clip doesn’t create a scroll container and doesn’t support programmatic scrolling. Unlike hidden, it also doesn’t establish a formatting context by itself; if that behavior was needed, display: flow-root may be relevant.

Check both axes. When one axis is neither visible nor clip, visible on the other computes to auto, and clip computes to hidden. That makes an isolated overflow-x edit easy to misread. MDN’s overflow reference documents these interactions.

Don’t remove intentional panel scrolling just to make a sidebar follow the document. Either make it sticky within that panel or move it into the layout region it should follow.

Give the sticky box room to move

Consider a two-column grid with a long article and a short navigation sidebar:

<div class="article-layout">
  <aside class="sidebar">Article navigation</aside>
  <main class="article">Long article content goes here.</main>
</div>

.article-layout {
  display: grid;
  grid-template-columns: 16rem minmax(0, 1fr);
  gap: 2rem;
}

.sidebar {
  position: sticky;
  top: 1rem;
  align-self: start; /* Keep this grid item from stretching vertically. */
}

This is an illustrative layout, not a benchmark or a claim about a production incident. Add enough article content to make the page scroll when trying it.

If the sidebar stretches to fill the row, reducing its height with align-self: start can give it travel space. If it’s inside a short wrapper containing only the navigation, inspect that wrapper too. The containing block needs to span the region you want the sidebar to follow.

Don’t apply align-self: start blindly to every flex layout. In a row flex container it affects vertical alignment; in a column container the cross axis is different.

What you observe	What to inspect next
It scrolls away immediately	Computed position, inset, ancestor overflow
It sticks briefly, then stops	Containing-block boundary and available travel
It stays in place but disappears behind content	Paint order and stacking contexts
It fails only on narrow screens	Active breakpoint rules and the sidebar’s rendered height

A z-index change belongs in the third row. It won’t change which container supplies scrolling. And fixed changes layout behavior, so use it only when that behavior is actually what you want.

If a title also spills out of this layout, inspect its width separately. The text-overflow ellipsis debugging guide shows how a flex wrapper can block truncation, and why clipping the whole parent can hide more than the text.

Send the AI agent the diagnosis, not just the symptom

A screenshot shows where the sidebar ended up. It doesn’t show which ancestor supplied its scrollport. Keep the screenshot if it helps explain the visual result, then add a text handoff like this hypothetical example:

Element: .article-layout > .sidebar
Observed: sidebar scrolls away during document scrolling.
Computed: position: sticky; top: 16px; align-self: start.
Ancestor: .page-shell has overflow-x: hidden; overflow-y: auto.
Intended: sidebar follows document scrolling until the article ends.

Inspect the source of .page-shell overflow before editing.
Preserve intentional clipping or scrolling; explain the tradeoff.
Do not replace sticky with fixed without checking layout requirements.
Verify at desktop and mobile widths, including the article's end.

Those values are example inputs, not measurements from your page. Replace them with your own findings and point to the responsible component when you can.

That handoff applies the same scoping principle covered in reducing Cursor’s context usage: identify the relevant element and source instead of sending the agent off to search everything. If you’re using Claude Code, the structured UI context section covers the same gap between pixels and selectors.

UICuts can help capture the element’s selector, computed styles, and DOM hierarchy, with an annotation describing the intended behavior. It doesn’t prove which scroll container caused the bug; that’s still the browser investigation above.

For a Copilot handoff, pair this report with the file-scoping advice in the GitHub Copilot context guide. For Cascade, the Windsurf guide covers giving it element data. If Cline is doing the edit, the Cline context guide explains why identifying the relevant file belongs alongside that data. Pick the guide for your tool; the CSS diagnosis stays the same.

FAQ

Does overflow hidden always break sticky?

No. It changes the scroll container sticky uses. The confusing case is scrolling the document while the sticky box belongs to an intervening container that isn’t scrolling.

Why does sticky stop at the end of my article?

That’s expected when the article region defines its containing block. If it stops too early, inspect the wrapper structure before changing the positioning mode.

What if the sidebar is taller than the screen?

Check whether its links remain reachable at narrow widths and increased zoom. Disabling sticky at those sizes may be better than keeping an oversized navigation panel stuck in view. Test the actual content, not just an empty sidebar.

Can UICuts fix sticky positioning automatically?

Use it to collect element context and annotate the bug, then send that context to your coding agent. You still need to identify the scrolling behavior and verify the resulting edit in the browser.

Key lessons learned

• Confirm the applied offset before investigating layout.
• Inspect ancestor overflow on both axes, and reproduce which container scrolls.
• Check available travel space before adding height or alignment rules.
• Give the agent the intended boundary and a concrete verification plan.

For CSS position sticky not working, start with one element and its ancestor chain. If you want to paste that inspection into an AI coding session, install UICuts from the homepage and annotate where the sidebar should stick and where it should stop. Then scroll all the way to the end of the article before calling the fix done.