Most headers scroll away. A sticky one doesn’t. It stays parked inside the browser viewport while the rest of the page keeps moving underneath it, which is why you can still see the menu three thousand pixels into a blog post.
Front-end designers put this on page headers and primary menus. The build is either one line of CSS or a short script, depending on how much the header is supposed to do.
It took a while to be safe to use everywhere. According to Can I Use, Chrome carried only partial support for the underlying position: sticky property until version 91 shipped in May 2021, despite early implementations dating back nearly a decade earlier.
What Is Sticky Navigation?
The label covers any navigation bar that holds its spot in the browser viewport during a scroll rather than sliding off-screen with everything else on the page.
It belongs to the wider family of persistent user interface patterns. Timing is the thing that separates it from an ordinary header, since it only locks into place once the page reaches a set scroll point.
The CSS version is a single declaration, position: sticky, and no script runs at all. The other version leans on JavaScript that toggles a class once a scroll threshold gets crossed. Every sticky menu on the web is one of those two wearing different styling.
Wikipedia’s current desktop layout is a plain example of the pattern. The article’s table of contents stays pinned in the left rail while the body text scrolls underneath it.
How Does Sticky Navigation Work?
See the Pen
A modern pricing page with sticky navigationby Bogdan Sandu (@bogdansandu)
onCodePen.
The element flips between two positioning states inside one property. Relative until the page scrolls past a set point, then fixed-like once it does.
The mechanics are defined in the CSS Positioned Layout Module, the specification the W3C maintains for how elements are placed on a page.
Position: fixed came first and does something similar. It locks an element in place, but from the very first frame rather than waiting for a scroll trigger.
CSS Position Sticky
position: sticky is a hybrid value. Declare it, give it an offset, and the browser handles the locking on its own.
It watches that offset, commonly top: 0, against the element’s nearest scrolling ancestor, and flips to fixed-like behavior the instant the offset is reached.
- No JavaScript needed for the basic stick-and-release behavior
- Works inside any container that has a defined scrolling context
The catch nobody warns you about: it breaks silently if a parent element sets overflow to hidden, auto, or scroll. No error, no warning, nothing in the console. The header just doesn’t stick.
This is a native CSS behavior, not a scripted one, so there’s no listener running in the background for the basic effect.
Frontend Mentor took exactly this route for the sticky menu on its resources page. One position: sticky declaration, no JavaScript, no extra package.
JavaScript-Based Sticky Navigation
Plain CSS handles the stick. It does not handle a shrinking header, a hide-on-scroll-down effect, or a class swap triggered at a specific pixel count.
Those effects need a bit of JavaScript that measures scroll position, or watches an element with the IntersectionObserver API, and toggles a class in response.
In practice that means detecting scroll position, or using IntersectionObserver to catch the moment the header crosses a marker, then toggling a class that changes height, background, or visibility. Throttle or debounce the handler so it doesn’t fire on every single pixel of scroll.
Written poorly, this is the thing that makes a page feel sluggish. Written with a debounced handler, it barely registers.
Sticky Navigation vs Fixed Navigation
Both keep a menu visible during scroll. The split is about document flow. Sticky stays in the normal page flow until its trigger fires, and fixed gets pulled out of the flow at first paint and never rejoins it.
| Pattern | Trigger Condition | Document Flow | Layout Shift Risk |
|---|---|---|---|
| Sticky Navigation | Locks at a defined scroll offset | Normal flow until triggered | Low, if space is reserved |
| Fixed Navigation | Locked from first paint | Removed from flow immediately | Higher without a manual offset |
| Static Navigation | Never locks | Normal flow throughout | None |
A standard site navigation bar set to position: static scrolls with the page and disappears once the visitor moves past it.
Fixed navigation anchors itself to the viewport the moment the page loads, so developers usually add top padding to the body to stop it from covering content underneath.
Amazon’s mobile product page is a clean example of fixed positioning in practice. Its add-to-cart bar stays pinned to the bottom of the screen no matter where the shopper has scrolled to.
Types of Sticky Navigation
Past the basic stick, a handful of named behaviors show up over and over. Shrink-on-scroll is the most common. Hide-on-scroll-down and its mirror, reveal-on-scroll-up, cover the rest.
Each one layers a different scripted effect on top of the same base position: sticky mechanic.
Shrink-on-Scroll
The header starts tall, usually with a large logo and generous padding, then compresses into a slimmer bar once the user scrolls past a set point.
Apple’s website is a widely cited example. Its top navigation bar visibly shrinks in height as a visitor scrolls down a product page.
Branding stays prominent on the first view and the screen space comes back for content. The cost is a scripted transition, usually built with CSS keyframes or a transition property, which adds a small amount of extra reflow.
Hide-on-Scroll-Down
- Header slides out of view once the user scrolls down past a small threshold
- Header slides back in as soon as the user reverses direction
- Requires tracking scroll direction, not just scroll position
This is one of the more noticeable micro-interactions on the modern web. Medium’s article pages hide the header on scroll-down and bring it back the instant a reader scrolls up.
You get maximum reading space on long-form content. You also get something that can feel twitchy on trackpads or momentum-scroll devices, where direction flips several times a second.
Reveal-on-Scroll-Up
Technically the same mechanism as hide-on-scroll-down, described from the opposite direction. The menu is absent by default and only reappears once the user scrolls upward.
Some implementations treat this as one combined pattern rather than two separate ones, since the underlying direction-detection script is identical either way.
Content gets full-height priority and navigation sits one scroll-tick away. The honest downside is that first-time visitors sometimes don’t realize the menu exists at all, because nothing on the initial screen hints at it.
Browser Support for Sticky Navigation
Every major browser in active use today supports position: sticky, which makes this a non-issue for almost any project starting now.
Can I Use puts current global support at 96.67% combined full and partial coverage, based on August 2026 StatCounter usage data.
That number wasn’t always this high. Chrome didn’t reach full support until 2021, and Internet Explorer never implemented the property at all.
The numbers worth keeping in mind:
- 96.67% global browser support today (Can I Use, August 2026 data)
- Baseline Widely Available status for the position property, meaning it has worked across major browsers since July 2015 (MDN Web Docs)
- Internet Explorer 11 never supported position: sticky, at any point in its lifecycle
- A parent element with overflow set to hidden, auto, or scroll will silently break the sticky effect, regardless of browser
Cross-browser gaps used to be the main reason developers reached for a cross-browser compatibility polyfill instead of the native property. That’s rarely necessary anymore.
Sticky Navigation and Core Web Vitals
The metric to watch is Cumulative Layout Shift, which measures how much visible content jumps around during a page’s lifespan.
Google considers a Cumulative Layout Shift score under 0.1 to be good, and a poorly coded sticky header is a common way sites miss that mark.
Here’s how the shift happens. A sticky or fixed header locks into place, the page never reserved space for it, and everything beneath it jumps the instant the lock engages.
The fix is straightforward. Reserve the header’s height in the layout, through padding-top on the body or a placeholder element, before the sticky trigger ever fires.
- Unthrottled scroll event listeners force the browser to recalculate layout on every scroll tick
- A debounced or throttled handler cuts that recalculation down to a handful of times per second
- Passive event listeners let the browser continue scrolling immediately instead of waiting on the handler
None of this is unique to sticky navigation. It’s the same reflow cost any scroll-triggered script carries, just easier to notice because the header sits at the top of every screenshot.
Sticky Navigation and Accessibility
One problem dominates here. A header that stays on top of the page can cover the very element a keyboard user just tabbed to.
That’s not a hypothetical edge case for web accessibility testing. It’s common enough that the W3C wrote a dedicated success criterion for it.
Keyboard Focus Handling
When someone tabs through a page, the browser scrolls the focused element into view. It has no idea a sticky header is sitting on top of that spot.
So the link or button technically has focus, responds to Enter, and is completely invisible to the person using the keyboard.
A few things fix it:
- Add scroll-padding-top set to the header’s height, so the browser stops short of the sticky bar
- Provide a skip link that jumps straight to the main content, bypassing the sticky menu entirely
- Test every focusable element in the header and the first screen of content, not just the page as it looks on load
WCAG Success Criteria Affected
WCAG 2.2, published by the W3C in October 2023, added Success Criterion 2.4.11, Focus Not Obscured (Minimum), specifically to cover this problem.
The rule is Level AA, and it requires that a focused component never be entirely hidden by author-created content such as a sticky header, a cookie banner, or a chat widget.
A sliver of the focused element peeking out from under the header is enough to pass. Full coverage is not.
Screen reader users benefit from a related fix. Mark the sticky header with an ARIA landmark role, such as role=”banner”, so the region gets announced clearly instead of read as an undifferentiated block of links.
Does Sticky Navigation Improve Usability and Conversion Rate?
On longer pages it usually does, mainly by cutting down the number of times a visitor has to scroll back to find the menu.
There’s an old study worth knowing about. In 2012, Smashing Magazine timed 40 participants completing tasks on matched sites, one with a standard header and one with sticky navigation.
The sticky version was 22% quicker to navigate, cutting roughly 36 seconds off an average five-minute visit.
The gain tends to show up in a few places:
- Fewer scroll-to-top actions needed to reach the menu
- Faster access to a persistent call-to-action button on long pages
- Lower perceived effort, even among participants who couldn’t identify what had changed between the two sites
It isn’t universal, though. Baymard Institute’s broader navigation research treats persistent navigation as one factor among many, not a fix on its own for a site with deeper usability problems.
A menu that’s always visible doesn’t help much if the categories inside it are confusing or mislabeled to begin with.
Sticky Navigation on Mobile
Mobile changes the calculation, mostly because screen space is scarce and thumbs, not cursors, do the tapping.
A full sticky bar that looks fine on a wide monitor can eat a noticeable slice of a phone screen, which is why most mobile sites shrink it down to something smaller.
| Placement | Common Use | Thumb Reach |
|---|---|---|
| Top-anchored bar | Logo, menu icon, search | Harder to reach one-handed |
| Bottom-anchored bar | Primary actions, add-to-cart, tab navigation | Easier to reach one-handed |
Most mobile sites collapse the main menu into a hamburger menu icon rather than keeping every link visible in the sticky bar.
That single icon, plus maybe a logo and a search glyph, is usually all that survives the jump from desktop to mobile.
Thumb Zone Placement
Steven Hoober’s 2013 UXmatters study, based on 1,333 real-world observations, found that 49% of people hold their phone in one hand.
The reach diagrams that ran with the column marked the top corners of the screen as the hardest area for a thumb to reach without shifting grip. That heuristic gets cited everywhere. Worth knowing that Hoober later cautioned those particular sketches were rough approximations rather than measured touch data.
Either way, a bar pinned to the very top of the screen sits in the zone people see easily but reach the least comfortably.
- Primary actions such as search, cart, or the main CTA work better anchored near the bottom of the screen
- Secondary items like a logo or account link can stay in the harder-to-reach top bar
- WCAG 2.2, the same guidelines version covered earlier for focus visibility, also added Success Criterion 2.5.8, requiring touch targets of at least 24 by 24 CSS pixels
Airbnb’s mobile site is a common reference point here. Its search bar condenses into a sticky pill near the top, but the filters and actions people tap most often sit lower on the screen, closer to where a thumb naturally rests.
This is one of the core reasons mobile-first design treats thumb reach as a layout constraint, not an afterthought.
How to Implement Sticky Navigation
See the Pen
E-commerce Product Detail Pageby Bogdan Sandu (@bogdansandu)
onCodePen.
The sequence is short and fairly predictable, whether the implementation is pure CSS or backed by a script.
Skipping a step, especially the overflow check, is the single most common reason it fails silently once it’s live.
- Wrap the header in a container and set position: sticky with a defined top offset, usually top: 0
- Check every ancestor element between the header and the scrolling container for overflow set to hidden, auto, or scroll, and remove or adjust it
- Reserve the header’s height in the layout before the sticky trigger fires, the same layout-shift fix covered earlier
- Add any scripted behavior, such as shrink-on-scroll or hide-on-scroll-down, using a debounced scroll handler or IntersectionObserver
- Test keyboard focus by tabbing through the page and confirming nothing lands underneath the sticky bar
- Run a performance check to confirm the layout stays stable, then ship the final stylesheet
The failure that wastes the most time: a parent element several layers up sets overflow to auto or hidden for some unrelated reason, and the sticky header simply never sticks, with no error or warning anywhere.
If the header’s height changes at different breakpoints, the offset needs to adjust too, which is where media queries come in.
Before shipping, run the compiled stylesheet through a CSS Minifier so the extra rules from a sticky implementation don’t add unnecessary weight to the page.
Sticky Navigation Tools and Platforms
Most modern site builders ship this as a built-in option, and most CSS frameworks hand you a utility class for it.
WordPress alone powers around 43% of all websites, and roughly 60% of the sites that run a known content management system, according to W3Techs’ ongoing survey.
No-Code Platforms
Webflow, Squarespace, and similar builders expose sticky navigation as a setting in the header panel. No code required.
- Webflow lets a designer set any element, not just the header, to a sticky position type directly in the Style panel
- Squarespace’s newer templates include a sticky header option under site-wide header settings
- Shopify themes commonly ship a sticky add-to-cart bar for product pages, configured through theme settings rather than custom code
The tradeoff is customization. A shrink-on-scroll or hide-on-scroll-down effect usually still needs a bit of custom code or a third-party embed, even on these platforms.
Frameworks and CMS Tools
- Bootstrap ships a sticky-top utility class that applies position: sticky with a preset offset
- WordPress themes and plugins add sticky headers through the customizer or dedicated settings
- Most component libraries for React, Vue, and similar frameworks include a sticky prop on their navbar component
- Tailwind CSS has no separate sticky component, since sticky positioning there is just a utility class applied directly to any element
Bootstrap’s navbar documentation covers the sticky-top class directly, alongside the older fixed-top alternative it has gradually replaced for this use case.
Plenty of sites skip the framework route entirely and build a header from scratch, often starting from a CSS header template and layering the sticky behavior on top.
When Sticky Navigation Does Not Work
It doesn’t help every site, and on some pages it actively gets in the way.
On articles, documentation, or blog posts meant to be read start to finish, a persistent header competes with the content for vertical space and starts to feel like clutter rather than help.
Hero-heavy landing pages have a similar problem. When the first screen already carries a large hero image and its own call-to-action, a sticky bar duplicating that same action right above it adds visual noise.
Then there’s hardware. A shrink-on-scroll or hide-on-scroll-down effect built with an unthrottled scroll listener can visibly stutter on older phones, turning a polish feature into a performance complaint.
And if something else already owns that edge of the screen, a sticky footer, a sticky sidebar, or a chat widget, the two will fight for room. Especially on mobile.
A landing page with one clear conversion path already visible above the fold rarely needs a second, competing call to action pinned to the top.
- Content-first sites where reading, not navigating, is the main task
- Single-page landing pages with a conversion path already visible before any scrolling
- Any layout where more than one persistent element is competing for the same edge of the screen
The test is simple. If removing the sticky header wouldn’t change how anyone uses the page, it isn’t earning its permanent spot on the screen.
FAQ on What Is Sticky Navigation
Is the Performance Cost of Sticky Navigation Worth It?
For most content-heavy sites, yes. A well-coded sticky header, one that reserves its height and uses a debounced scroll handler, adds negligible reflow cost, and the usability gain from persistent navigation usually outweighs that small footprint.
What Causes Sticky Navigation to Overlap or Break Page Content?
Overlap usually comes from a missing top offset or a header with no defined height, so content slides underneath it instead of stopping short. A missing z-index lets other elements render on top of the bar instead of below it.
What Is the Ideal Height for a Sticky Header?
No fixed number exists. Height depends on content density and brand needs, though most implementations trend toward a compact bar, especially after a shrink-on-scroll effect fires, since taller headers eat into space visitors came to use for content, not chrome.
Is Sticky Navigation the Same Thing as a Sticky Sidebar or Sticky Footer?
No. All three share the same position: sticky mechanic, but sticky navigation refers specifically to the primary menu.
A sticky sidebar holds secondary content like a table of contents, and a sticky footer pins a bar to the bottom edge.
What Should You Check First in What Is Sticky Navigation?
Start every audit with the overflow check, since a single ancestor element set to hidden, auto, or scroll silently cancels the effect before any visual bug ever appears on the page.
After that, work through the rest in this order:
- Overflow ancestors
- Reserved header height
- Keyboard focus path
That order follows visibility, not severity. An overflow conflict hides inside the DOM, a missing reserved height shows up instantly as a layout-shift score, and a blocked focus path only surfaces once someone tests with a keyboard.
Chrome reached near-universal support for the underlying property by 2021, yet the accessibility criterion covering it, WCAG 2.2’s focus-visibility rule, did not exist until October 2023.
Most sites clearing the compatibility bar today remain unaudited against that newer compliance rule. Running a full web accessibility checklist against the finished header closes that gap in one pass.
Many of his resources are available on various design marketplaces. Over the years, he's worked with a range of clients and contributed to design publications like Designmodo, WebDesignerDepot, and Speckyboy, Slider Revolution among others.
- What is Backend in Web Development? - September 13, 2026
- What is Frontend Development? - September 11, 2026
- How to Make a Button in Figma: Design Best Practices - September 10, 2026
