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.
FAQ
How do I stop layout shift when a modal opens and the scrollbar disappears?
Add `scrollbar-gutter: stable` to your html element in CSS. This tells the browser to reserve space for the scrollbar even when it’s not visible, so setting body overflow to hidden when opening a modal won’t cause your navbar, hero image, and centered content to jerk 15 pixels to the right. No JavaScript width calculations or negative margins needed.
What’s the difference between scrollbar-gutter stable and always?
The `stable` value reserves scrollbar space only when the container can potentially scroll, keeping the space empty if the scrollbar isn’t currently there so layout stays put when it appears. The `always` value exists too, but the article’s author hasn’t found a production use case where `stable` wasn’t the better choice, since `stable` is smart enough to know when it’s needed.
Why is my centered content off-center after adding scrollbar-gutter: stable?
Reserving gutter space on only one side shifts centered containers (like a `max-width: 1200px; margin: 0 auto;` wrapper) slightly off-center. Fix it by adding the `both-edges` keyword: `scrollbar-gutter: stable both-edges`. This applies a matching gutter to the left side as well, keeping symmetrical containers perfectly balanced regardless of whether the scrollbar is currently visible.
Is scrollbar-gutter supported in all browsers in 2026?
As of February 2026, support is effectively universal across Chrome, Edge, Firefox, and Safari, with Can I Use showing near-complete coverage. One edge case appeared on Chrome 143 Canary, where the gutter painted oddly over a fixed sidebar using a custom dark-mode scrollbar theme; giving the fixed elements an explicit higher z-index resolved it, since the property does affect the painting layer.
