You know the jump. We all know the jump.
You click a button to open a modal. The body overflow gets set to hidden to prevent background scrolling. The scrollbar vanishes. And then—thwack—your entire navbar, your hero image, and that perfectly centered text all jerk 15 pixels to the right.
It’s ugly. It feels cheap. And for the longest time, fixing it was a nightmare of JavaScript calculations and negative margins.
Well, that’s not entirely accurate. I was reviewing a junior dev’s PR yesterday (running Next.js 16.1, if you’re curious) and saw them importing a heavy hook just to measure the scrollbar width. I had to stop them right there. “Delete this file,” I said. “Just use CSS.”
And it’s 2026. We don’t need JavaScript to handle scrollbar spacing anymore. We have scrollbar-gutter.
The Old “Hack” vs. The Real Fix
Back in the day—and by that I mean like 2022—we used to do some truly unholy things to prevent layout shift. Remember this?
const scrollbarWidth = window.innerWidth - document.documentElement.clientWidth;
But the CSS property scrollbar-gutter handles this natively. It tells the browser: “Hey, reserve space for the scrollbar, even if it’s not currently visible.”
Here is the only line of CSS you actually need:
html {
scrollbar-gutter: stable;
}That’s it. Seriously.
Stable vs. Always
I’ve seen some confusion about the values here, so let’s clear it up. You mostly have two options that matter:
auto: The default behavior. Layout shifts happen. We hate this.stable: The good stuff. It reserves space only if the container can potentially scroll. If the scrollbar isn’t there, the space is still kept empty, so the layout doesn’t move when the scrollbar eventually arrives.
There is technically an always value, but honestly? I haven’t found a production use case for it where stable wasn’t better. stable is smart enough to know when it’s needed.
The “Centered Content” Gotcha
Here’s the thing that trips people up. If you have a centered container (like a max-width: 1200px; margin: 0 auto; wrapper), adding scrollbar-gutter: stable to the html element can make your content look slightly off-center.
The fix is the both-edges keyword:
html {
scrollbar-gutter: stable both-edges;
}This adds a matching gutter to the left side of the container. It keeps everything perfectly symmetrical.
Browser Support and Real-World Quirks
As of February 2026, support is effectively universal. Chrome, Edge, Firefox, and Safari all handle this fine. Can I Use shows near-complete browser support for the scrollbar-gutter property.
However, I did run into a weird edge case last week working on a dashboard layout. We had a sidebar with position: fixed and a main content area with scrollbar-gutter: stable.
On Chrome 143 (the Canary build), the gutter was painting on top of the fixed background in a weird way when using a custom dark mode scrollbar theme. The fix was simple—ensure the fixed elements had a higher z-index explicitly—but it’s a reminder that this property does affect the painting layer.
Why aren’t you using it yet?
I still see sites—big ones—that shift when I navigate. It’s low-hanging fruit for UX.
Stop calculating scrollbar widths in JavaScript. Please. It’s 2026. Use CSS instead, as shown in Stop Over-Engineering: 8 HTML Attributes That Replace Your JavaScript.
And if you’re struggling with layout shifts in general, check out CSS Cards: Why Your Layout Still Breaks and CSS Grid Lanes: A Better Way to Manage Layouts.
