Using 100vw is now scrollbar-aware (in Chrome 145+, under the right conditions)

~

The problem with CSS Viewport Units

The problem with CSS Viewport Units (vw and friends) is that those units do not take the presence of classic scrollbars into account. So when you size something to be 100vw wide, it is sized to fill up the entire viewport width … which can cause overflow when there is a vertical scrollbar present.

In the following screenshot of this demo, the blue box is sized to be 100vw wide. Because of the presence of the vertical scrollbar (which reduces the viewport’s final width) the blue box becomes too wide for it to fit inside the “viewport with scrollbar taken into account”, causing the horizontal scrollbar to appear.

This “pointless” horizontal scrollbar lead Šime Vidas filing this issue at the CSS Working Group in 2021.

~

Cycles

A gut reaction to this “pointless” horizontal scrollbar problem is that CSS is stupid and that viewport units should simply take the presence of the scrollbar into account. The problem there is that this can’t “just” be done, because of cycles.

Say you have a page that contains only a box that is sized to be 100vw × calc(100vh + 1px). With classic scrollbars, this results in the page overflowing in both directions. If the vw unit were to adjust itself by subtracting the scrollbar size in that case, you’d be stuck with the following cyclic behavior:

1. Page is overflowing vertically (because of the calc(100vh + 1px))
2. Browser shows the vertical scrollbar
3. Page is now also overflowing horizontally (because of the 100vw)
4. Browser subtracts the scrollbar sizes from the viewport units on both axis
5. Page is no longer overflowing horizontally
6. Browser no longer shows the horizontal scrollbar
7. Browser no longer subtracts the scrollbar size from the vh unit after all
8. Go back to step 1

So no, simply subtracting the scrollbar’s size isn’t a viable solution here.

~

Always-present scrollbars (or scrollbar gutters)

A thing Firefox had back in the day – but that it later removed because it wasn’t interoperable (source) – was that they did subtract the size of the scrollbar from the vw unit, but only when the page was set to always show its scrollbars, which could be triggered by declaring overflow-y: scroll on it.

This approach actually works, because the presence of the vertical scrollbar is unconditional in that case – it is always present.

1. Browser shows the vertical scrollbar, regards of whether the page is currently overflowing or not
2. Subtract the scrollbar size from the vw unit
3. No need to show a horizontal scrollbar

At the end of 2023 we resolved with the CSS Working Group to resolve on this behavior:

RESOLVED: if overflow: scroll is set on the root element (not propagated from body), account for the default scrollbar width in the size of vw. […]

So that means that if you have overflow-y: scroll declared on html it will take the size of the vertical scrollbar into account for determining the value of 100vw. The same applies to the vh-unit and the horizontal scrollbar.

What is also interesting, is that with the CSS Working Group we also resolved to take scrollbar-gutter: stable (on the root) into account as a trigger for this.

RESOLVED: […] Also take scrollbar-gutter into account on the root.

My suggestion to you here would be to declare scrollbar-gutter: stable over overflow-y: scroll on html, because the latter always draws a scrollbar, even when not necessary.

Translated: Put this in your CSS reset if you hadn’t done so already:

html {
  scrollbar-gutter: stable;
}

~

Don’t break the web

It took some more back and forth after the original resolution was taken because there were concerns that this would break existing websites: if a site already manually subtracted the (guesstimated) scrollbar-size from 100vw, they would visually break.

Early 2024 I ran the numbers by querying the HTTP Archive to see how many sites actually used the calc(100vw - var(--scrollbar-width)) pattern in combination with overflow: scroll declared on html.

In total 12,089,606 root pages found in the HTTP Archive November 2023 Dataset were scanned. Out of those +12 million scanned pages:

• 324,866 use the calc(100vw - <length>) pattern (2.6871512603%)
• 4,112 have overflow: scroll _declared_ on the root element (0.03401268825%)
• 72 pages use both (0.0005955529072%)

Of those 72 pages, only 38 seem to use the calc() expression to cater for scrollbars (0.0003143195899%). The ignored 34 pages did a calculation with a <length> greater than 50px which seems like an unlikely width for a scrollbar to have.

That number is small enough to justify this breaking change to be introduced – especially because it doesn’t lead to data-loss and the origins that use it were not part of the top 1000 websites – so with the CSS Working Group we took a second resolution mid 2024 to continue with this plan.

~

Scrollbar-aware viewport units are available in Chrome 145

I was happy to see that last summer the CrBug concerned with this got assigned, and that the CLs to fixing this followed soon (thanks, David!). All necessary CLs landed in November / December 2025, and on the very last day of 2025 the issue got marked as fixed 🎉

This week Chrome 145 goes to beta. This release includes the change as described above: viewport units are now scrollbar-aware if document scrollbars are forced on the opposing axis or if space for a scrollbar is reserved.

In Chrome 145, the demo shown earlier renders like this, without any “pointless” horizontal scrollbar:

Currently, Chromium-based browsers are the only browser to support this. Unfortunately there is no CSS-only way to feature detect this change.

~