What is a scrollbar styler?
Scrollbars are the one piece of browser furniture that never quite matched the rest of a design, and for years the only way to change one was a set of non-standard WebKit pseudo-elements. Then a standard arrived with two properties, scrollbar-width and scrollbar-color, and Firefox implemented those instead. So we're in the odd position of needing both, and neither on its own covers everyone.
Then it got worse. Chrome 121 added the standard properties too, and gave them precedence, so an element that sets scrollbar-color has its ::-webkit-scrollbar rules thrown away. Stylesheets that had shipped both for years, one for Firefox and one for everything else, quietly lost their rounded thumbs and hover states overnight. Nearly every scrollbar generator on the web still emits that broken pair.
This tool writes them so they don't collide. The webkit rules stay unwrapped, and the two standard properties go inside @supports not selector(::-webkit-scrollbar), which only matches in browsers that have no webkit rules to lose. Firefox gets its half, Chrome keeps the detailed half, and nothing is discarded. The other two modes are there so you can see the difference for yourself.
The preview is the other half of the point. Two panels here genuinely scroll, one down and one across, and they're running the exact CSS in the box below. You can grab the thumb, hover it, and see whether it's actually findable, which a swatch of color never tells you. There's also a contrast reading between thumb and track, because a scrollbar is a control you have to spot and grab, and WCAG asks for 3 to 1 on controls.
How to Use This Tool
- Start from a style. Minimal is the safe one for a content site. Chunky suits an app panel where the bar is used constantly.
- Set the two colors. Thumb first, then the track behind it. Watch the contrast bar as you go.
- Size it. Ten to fourteen pixels is comfortable. Below eight is a fiddly target, especially on a trackpad.
- Add a gap if you want one. The gap draws the thumb inside the track rather than filling it edge to edge, which reads as lighter.
- Scroll the preview. Both panels are live. Drag the bar, not just look at it.
- Copy the whole block. The two standard properties and all the webkit rules go together.
Common Use Cases
Restyling a scrollbar is worth it in a few specific places and a waste of time everywhere else.
- Dark interfaces: the strongest case by far, since a default light scrollbar against a dark panel looks like a bug.
- Inner panels: sidebars, chat threads, code blocks and dropdown lists, where a full width system bar looks heavy against a small area.
- Design systems: one scrollbar rule applied consistently so every scrolling region in a product matches.
- Kiosks and embedded screens: where you control the hardware and can make the bar as chunky as a finger needs.
- Horizontal carousels: a slim visible bar is far better than hiding it, because it tells people there's more to the side.
Styling the rest of the panel? The CSS Box Shadow Generator and the CSS Border Radius Generator handle the container, and the CSS Cursor Viewer covers the other bit of browser furniture worth knowing about. Or browse all our free developer tools.
Frequently Asked Questions
Why are there two completely different sets of properties?
History. WebKit shipped ::-webkit-scrollbar in 2009 and it was never standardized, so Chrome, Edge and Safari support it while Firefox never did. The standard that eventually arrived, scrollbar-width and scrollbar-color, is deliberately much simpler, taking a width keyword and two colors and nothing about radius or hover. For years you shipped both and each browser took the half it understood. Since Chrome 121 that no longer works, which is what the mode selector on this page is about.
Why did my custom scrollbar stop working in Chrome?
Because Chrome 121 started honoring scrollbar-width and scrollbar-color, and the spec says those win over the old pseudo-elements. If your stylesheet sets scrollbar-color anywhere on that element, every ::-webkit-scrollbar rule you wrote for it is ignored, so the bar falls back to a plain colored one with square ends. The fix is to move the two standard properties inside @supports not selector(::-webkit-scrollbar), which is what the default mode here generates.
Should I hide the scrollbar completely?
Very rarely. A hidden bar removes the only signal that a region scrolls, and on a desktop without a trackpad it also removes the way to scroll it. It's defensible for a carousel that has its own arrows, or a mobile only view where bars are already overlaid and temporary. Everywhere else, a slim styled bar does the job without lying about what the page can do.
How do I inset the thumb from the track?
With a border in the track color plus background-clip: content-box, which is what the gap control here generates. It looks like padding, but a webkit thumb doesn't take padding, so the border is standing in for it. The tradeoff is that the border color has to match the track exactly, which is why the tool keeps them in step.
Why does my page jump sideways when content gets longer?
Because the scrollbar appeared and took width from the layout. scrollbar-gutter: stable reserves that space up front, so nothing moves when the bar shows up. It's one of the most useful properties on this page and almost nobody knows it exists. Use both-edges if you need the reserved space mirrored so centered content stays centered.
Do these rules work on the whole page?
Yes, put them on html rather than a class. On the root element the standard properties propagate to the viewport scrollbar. One catch is that some browsers take the styles from html and some from body, so applying them to html is the reliable choice, and mixing the two is what makes results look inconsistent.
Will this work on iOS and Android?
Mostly it won't matter. Mobile browsers use overlay scrollbars that appear while you're scrolling and fade out, and they largely ignore custom styling. That isn't a problem, since a floating temporary bar is the right pattern on a touch screen. Style for desktop and let mobile do what it does.
Is a custom scrollbar bad for accessibility?
It can be, and there are two things to get right. Contrast, because someone has to find the thumb, which is why this tool measures it against the 3 to 1 threshold for controls. And size, because a very slim bar is hard to hit for anyone with reduced motor control. Keep it above about 10 pixels and clearly visible against the track and a custom bar is fine.
