I recently heard a designer say something to the effect that modern web designs don't use visual scrollbars - or at least they're only visible when scrolling. I'm a front-end developer and hadn't really heard this. Is there any truth to this? Specifically my question is:

For a web app, when content is scrollable:

  1. Should there ever be visible scroll bars (and why)?
  2. Should there ever not be visible scroll bars (and why not)?
  • 138
    That's some grade-a poor design thinking, on the part of that designer. Commented Sep 9, 2019 at 15:17
  • 52
    Yeah that's subjective opinion at best, and just plain wrong at worst. It's the sort of thing an uninformed designer dismissively says without considering usability impact, and I can pretty confidently guess they don't have any worthwhile data to back up that claim.
    – tobybot
    Commented Sep 9, 2019 at 17:32
  • 58
    @sudorm-rfslash counter-opinion: I love them! I like to be able to immediately click in the bar away from the thumb and use that as a mouse-based page down, or grab the thumb and scroll a dozen pages in a flash.
    – sintax
    Commented Sep 9, 2019 at 19:26
  • 66
    Eliminating scroll bars is an example of trying to force innovation in areas that are already mature and highly functional. (Which also describes entire sectors of the software market.) Commented Sep 9, 2019 at 23:48
  • 51
    There certainly are designers that think that, and those people should be banned from computers for life. Commented Sep 10, 2019 at 2:27

11 Answers 11


Yes there should.

Visible scroll bars are an affordance "this page is scrollable"

Without visual hints such as this the functionality might be missed.

  • 46
    Which happens to me all the time on mac because they don't show the scrollbars by default. Commented Sep 10, 2019 at 4:06
  • 28
    @BlueRaja-DannyPflughoeft This behavior is only observed when you're using a trackpad, if you're using a mouse, the scrollbar is supposed to be always visible. There is a setting in System Preference > General to always display/hide the scrollbar regardless of pointing device.
    – zakinster
    Commented Sep 10, 2019 at 7:47
  • 1
    Microsoft applications like Outlook and Word also have this problem. Commented Sep 10, 2019 at 14:58
  • 4
    Nothing worse than turning up to board, and you have not booked because the final button was off the page. Life changing events. Nested scrollable areas need visual cues at least.
    – mckenzm
    Commented Sep 11, 2019 at 3:31
  • 8
    And even if you know the page is scrollable, a scrollbar also tells you where on the page you are and how big portion of the page you're seeing.
    – JiK
    Commented Sep 11, 2019 at 13:14

Some modern design guidelines certainly disprefer persistently-visible scrollbars, but not all. For example, in the Material Design guide, for menus, if a menu is scrollable, it should show a scrollbar. In any case, if your content is scrollable, it should be clear from looking at it that it affords scrolling.

It's up to an individual designer or guideline whether that affordance is cued by a scrollbar that clearly indicates how much you can scroll down (traditional), a "read more" link or arrow pointing down-screen (like on many modern app homepages or blogs), or a fade-out as you approach the edge of the content area that implies that you can move that direction to see more or more clearly, but the affordance itself is the necessary component. It would be poor design to present content that can be scrolled but not indicate that scrollability to the user. It could frustrate the user or cause them to miss important information or calls to action.

  • 82
    Yes. Just yesterday I didn't realize there were more options available in a dropdown menu because it didn't show scrollbars. I eventually figured it out but it was annoying to have to do that.
    – CramerTV
    Commented Sep 10, 2019 at 1:37
  • 5
    To add: Netflix uses different methods at once. A permanent, lazy-loading vertical scrollbar and one title being cut off horizontally to show that there is a 'carousel' which supports showing more content horizontally. Commented Sep 10, 2019 at 14:11
  • 8
    Someone tell Apple this. For several releases they've made Mac OS scroll bars optional, and I think it defaults to off.
    – Barmar
    Commented Sep 10, 2019 at 15:02
  • 7
    @jamesqf It's a skeuomorphic allusion to human vision: items on the periphery are "out of focus," but you're still aware they're there and you can bring them into focus if you wish. I'm having trouble thinking of any specific applications that do this, but I've most often seen it in carousel UIs. Commented Sep 11, 2019 at 1:52
  • 5
    @Barmar Someone has: fastcompany.com/3053406/how-apple-is-giving-design-a-bad-name
    – James_pic
    Commented Sep 11, 2019 at 9:38

As a mouse user, I abhor scrollable content that doesn't give me a view of and access to scroll bars.

  1. The scroll bar is a control. It allows me to quickly navigate large pages no amount of finger-scrolling, scroll-wheeling, etc. can compare with. It also gives me more precision for most pages than my scroll-wheel.

  2. The scroll bar gives me information. It allows me to quickly determine how long it will take to read the content on the page (presuming a decent scroll bar whose handle: gutter ratio is equal to the screen: page ratio) and tells me how far through the page I've gotten. It also gives me an index to determine where I'm at on the page if I want to quickly scroll to the top and back down.

  3. The scroll bar takes up an insignificant amount of space. Right now, my screen is at 1920 x 1080 = 2.1 Mpx. The Firefox window with this page in it is at 1125 x 905 = 1.0 Mpx. The scrollbar is 16 x 816, taking up 13 Kpx total, or 1.3% of my screen. My monitor is pretty close to me because I use it for gaming, so I tend to keep my window narrower than the monitor anyways, so the scrollbar is effectively taking up no space at all.

  4. There are occasions when I don't even know the content is scrollable, though I tend to try scrolling with the wheel without even checking the bar, so I doubt this is a huge issue for web pages. For desktop applications that don't typically scroll, it would be a bigger problem.

  5. If you want a hideable scrollbar, it should appear any time I manually scroll (via mouse wheel, keyboard keys, trackpad, etc.), and any time I move my mouse towards the right edge of the screen.

Mobile devices are trickier, since the scrollbar takes up such a large amount of space, especially if it's big enough to use.

  • A. I typically solve the issue by switching to desktop view (I've yet to see a website whose mobile version is as good as, let alone better than, the desktop version, so I default to desktop view anyways). Then I zoom way out, scroll down, then zoom back in. It's faster and more precise than trying to scroll, scroll, scroll while zoomed in, and doesn't require a grabbable scrollbar. (It also allows me to zoom in for better views of images, diagrams, etc., which most mobile sites inexplicably refuse to allow.)

  • B. Firefox on Android has a non-accessible scrollbar to tell me what part of the page I'm on (for both desktop and mobile versions of a site), as does the default "Internet" browser. I use these just like I would on a desktop browser with a mouse for indexing and determining page length.

  • C. I also tend to only view large webpages on a proper monitor, so it's much less likely I'm on a mobile device trying to scroll through a 900-page .pdf or something. If your web-app never gets more than two or three screens long, scrolling is much less of an issue.

  • D. It's also worth noting that touchscreen finger-scrolling is typically both faster and more precise than using the mouse wheel, so a page has to be much larger before it's hard to navigate quickly.


For mouse (or trackpad or trackball) setups, I think the scrollbar should always be visible and grabbable. As a minimum, it should appear when scrolling or when moving the mouse near the scrollbar.

For mobile touchscreen setups, I think the scrollbar should always be visible when scrolling, but doesn't need to be grabbable, and should probably hide when not scrolling to reduce wasted space.

I haven't messed with tablet / iPad or larger touchscreens, so I'm not sure how I feel about those.

Of course, having the option to change visual styles (either through temporary cookies or through stored user settings, depending on whether your user is a guest or has an account) is the best bet, but you should default to something functional.

  • 4
    Well, there are websites where their desktop version is as bad as their mobile version...
    – Ángel
    Commented Sep 10, 2019 at 23:34
  • Rather than having the scrollbar totally hide itself when not being used, it can shrink horizontally to just enough width to show the visible indication of how far down the list is currently scrolled, but as soon as user intent to scroll is signaled, it could widen to be easier to grab. Commented Sep 11, 2019 at 17:53
  • @MontyHarder Its actually hard to do this, take an example at the windows 10 start menu, it responds to slow for this (I don't use my scroll wheel there, because the smooth scrolling gives me headaches, and windows never put an option in the accessibility tab to turn it off)
    – Ferrybig
    Commented Sep 12, 2019 at 8:58
  • Now that iPadOS 13.4 officially supports mice, and with reference to the question at the end of this comment, would you be able to update your recommendation for iPads with a mouse registered to them? In my view, the scroll bar should be visible at that time. apple.stackexchange.com/q/387631/57188
    – bjornte
    Commented Apr 8, 2020 at 7:42

This viewpoint comes primarily from the Mac environment, where scrollbars are typically displayed briefly when content first appears, then fade out. When scrolling occurs (user triggered or otherwise), the scroll bar reappears. Only the handle is visible (as a semi-transparent rounded black bar); no arrows or gutter. If the cursor is over the scroll bar when it appears, it becomes wider and allows dragging with the cursor. At no point does the content change size; it behaves as if the scrollbar were not present, and the scrollbar is rendered on top.

This applies when using trackpad or trackpad-like input mechanisms (i.e. a laptop). Regular scrollbars are still displayed by default when using a mouse.

Of course, this also extends to mobile; iOS uses almost identical behaviour (minus cursor interaction). In fact I think it started on iOS (where scrollbars would be too small to tap reliably) and migrated to macOS.

Overall, this has advantages and disadvantages:

  • Not needing to make space for scrollbars simplifies the page design (fewer distracting elements) and allows more space for the content, especially when multiple places can scroll.
  • Users on mac are accustomed to this behaviour and expect it.
  • There is no jump in content size when an area suddenly becomes scrollable, which also fixes a common ambiguity where a scrollbar can be needed so long as it is visible, and not needed if it is hidden (e.g. due to text wrapping).

  • On the negative side, as has already been mentioned, you need to come up with another way to indicate the content is scrollable. Not such an issue for the main part of a webpage because this is expected anyway, but can be an issue for internal content depending on user expectations. The initial flash helps, but is not always enough.

  • The user interaction for jumping to another location in the document is clunky; the user must move their cursor to where the scroll bar will appear, scroll slightly with the mouse wheel or "2-finger scroll", grab the scroll bar when it appears, and drag to the desired location. Momentum scrolling helps to avoid this in some cases.
  • Because the scrollbar appears on a transparent background, if the background is dark it can be hard to see. macOS provides a white alternative scrollbar which can be used in this case (I believe browsers automatically switch to this if the background is sufficiently dark, but it isn't 100% foolproof). Also it gives the bar a subtle glow (or shadow) as a just-about-good-enough fail-safe.

If possible, of course, stick to browser-native components for this sort of thing. They will ensure each user gets a natural experience for their platform (I've certainly seen a lot of websites try to replicate momentum scrolling and elastic scrolling with atrocious end results). Mac users won't thank you for forcing visible scrollbars where they wouldn't expect them, and Windows users won't thank you for hiding scrollbars where they would expect them.

  • 3
    +1 Hi Dave, thanks for your contribution to UXSE. Some very good points covered, and also pretty detailed context to help address the question raised. Looking forward to more of your answers (or questions) :)
    – Michael Lai
    Commented Sep 10, 2019 at 0:25
  • 7
    And a survey of Mac users will reveal that I am not the only one who has found this a major nuisance in real life. I have to scroll with the track pad to make the scroll bar appear, and then if I don’t get my mouse on the handle fast enough, it disappears again. Often it’s easier to spend half a minute flinging the page up with the trackpad to get to the bottom of a ridiculously long web page.
    – WGroleau
    Commented Sep 10, 2019 at 2:27
  • 4
    @WGroleau: You should be able to turn them back on. I rarely use Mac-based PCs but this article from 2018 suggests it's pretty easy to get the functionality back. There are also options for Word for Mac and probably most others.
    – MichaelS
    Commented Sep 10, 2019 at 2:40
  • 2
    Where I have to add that especially Windows still has its chunky scrollbars of the 1990ies. I usually work with Gnome or Cinnamon, both having rather thin scroll bars in their default themes. So it is not just a matter if the scrollbars are there or not at all, but also if they are not too pushy. Commented Sep 10, 2019 at 7:15
  • 1
    "Users on mac are accustomed to this behaviour and expect it" i.e. Stockholm Syndrome. ;) Commented Sep 10, 2019 at 16:20

The removal of scroll bars in my view is another example of the idiotic and shallow ideology of putting style over functionality. This is back to front to how it should be and is indicative of the dumbing down of society to me. Scroll bars serve an important functional purpose that other alternative methods cannot always replicate. I think the change is partly based on the notion that people use touch screens so it is therefore not needed, but many people still do not. Many alternative methods require extra concentration and finesse to manipulate which is a drain of energy I'd rather spend on doing work, rather than fighting with a bad user interface. Traditional scrolling methods usually go together with keyboard scrolling by pressing the arrow down key, which I find much easier than other methods that require more concentration, but with scroll bars being removed, keyboard arrow scrolling also sometimes disappears with it which should be a BIG no-no! An example is The big F social network has caused irritation constantly with it's "dynamic' scrolling style whilst scrolling up through msg history, and where you don't know whereabouts you are in the conversation while scrolling up, but then you scroll up past a certain point and suddenly an extra load of conversation history is loaded and you end up jumping far ahead of where you wanted to be.

I think it's also partly ignorance, and partly a desire to save resources and bandwidth on the servers to save companies money at the expense of user experience. It's also about dumbing things down for idiots to make things "easier" to use for very basic commands, at the expense of making things more troublesome for anyone who is not dumbed down and might want to do something ever so slightly out of the ordinary. I hope blockchain heralds the end of this era of sacrificing user experience to save money, and we can have systems that work quickly and are hassle-free for both basic and advanced users.

For example, wouldn't it be great if software like skype and F messenger let you instantly scroll to the very beginning of your msg history instead of waiting forever for section after section to load?! I've always suspected that is to save resources of loading the whole lot at once. However, if someone with a bit of intelligence and nuanced thinking were designing this,(more common in blockchain circles than corporations I hope), we could all have our cake and eat it. We can save resources (which is still not a trivial thing even in the blockchain), and get the info we want instantly without having to put up with this hideous page by page loading system.

Simply layout the framework of the whole timeline history on a scroll bar along with dates that pop up as you scroll. As soon as you let go on the mouse button or strop scrolling, that particular section can load. If you want to go right back to the beginning, scroll right to the top and only the first page needs to load. If you do need everything to load straight away though, to search a keyword for example, then just provide a simple button that can be pressed if necessary to get the whole msg history or history of whatever it is you were scrolling through.

If someone signals specifically it is necessary for all that to load, then the blockchain should accommodate the resources. This is the difference between it and corporations on the old model, who I suspect would be reluctant to allow even those that specifically need everything to load, to be able to do so to protect their resources for their filthy profit motive and screw the user. This is why we need blockchain, and preferably the open version.

  • 5
    Hi Lex, welcome to UX.SE. Would you mind taking a moment to edit your question to make it more neutral? The most appropriate answers for this site are neutral in language and tone, while providing real-world examples or research to support their claims, if possible. Feel free to stop by the tour to get an idea of how things work around here. Thanks! Commented Sep 10, 2019 at 15:01
  • 1
    Agree with you totally lex. Apple and the like are sliding into 'crappy corporation syndrome'. As a developer I can say that its easy to implement persistent, by overlaid & minimal scroll bars that solve all the cons. and the pros drive a better UX. But in self-confident old-gaurd companies, groupthink rules, and common sense goes out the door. Let's hope they get it turned around before they end up like Sears.
    – FastAl
    Commented Sep 11, 2019 at 21:08

As a mixed point of view...

Horizontal scroll bars are usually a bad thing. It may mean you've optimised for the screen width of a PC monitor, which doesn't translate well to mobile devices. When scrolling down, reading the entire page needs lots of left-right scrolls each screen of content. And conversely those sites will have wasted space on larger screens. (Older readers, remember websites saying "Best viewed at 1024x768"? Yeah, those.) We shouldn't have to put up with that in 2019 -this isn't the 1990s and we're not still using Netscape Navigator. Just don't go there.

Vertical scroll bars on the other hand are fine. We're intuitively used to scrolling down something - think of how you'd read a paper newspaper, for example. The whole page is easily visible with just up/down scrolls.

There's a school of thought that more than 2 or 3 screen fulls of content is too much though. After that it gets hard to find stuff. So whilst scroll bars work, don't let it lead you to unlimited length pages!

  • 1
    Of note, this relatively-sparse page takes up 8.6 screens at my current window size, and isn't that difficult to navigate. Though I do think it would be nice if there was a way to collapse SE answers to some kind of summary that could be scrolled through more readily. On the horizontal scroll front, I think the problem is when you have to scroll horizontally and vertically to read text. It's not so bad for viewing images or moving menus and toolbars offscreen to maximize the text area (though collapsible / resizable sidebars are probably better).
    – MichaelS
    Commented Sep 10, 2019 at 10:24
  • @MichaelS Agreed, but it can still be a pain to scroll up and down a long way. SE is fairly clearly laid out too, and follows a format we're familiar with, and is a site we voluntarily interact with. If the site was 8 pages, in some convoluted format, to do something like taxes which no-one really wants to mess about with, then I think we'd be less happy with it. It's all just rules of thumb, of course. Long pages may be absolutely fine - they're just a UI smell which suggests there could have been a clearer way to do it. (Like you say, collapsing answers here, for example.)
    – Graham
    Commented Sep 10, 2019 at 11:46
  • Frankly the mobile device should still cope. Otherwise you have the wrong device. This is what the presentation layer is for. I should not have to RDP to a desktop to view this crap. It works when it is done well. But how often is that? Everything shrinking and moving to the point where utility is lost. Or one or two giant svg characters on my screen...... Swiping to scroll is not hard.
    – mckenzm
    Commented Sep 11, 2019 at 3:38
  • @mckenzm Cope, yes. Having to scroll right/left as well as up/down to find out what's hiding in the corners, also yes. And I know of websites with nested menus which really don't play nicely with a phone screen.
    – Graham
    Commented Sep 11, 2019 at 7:21
  • While I agree you should generally avoid horizontal scrolling, there are times when it is the best thing to do, like when displaying a data table. The user may just be interested in a couple columns anyway and horizontal scrolling to the one you want is easier than trying to jump up and down when it is reflowed vertically (For example) Commented Sep 12, 2019 at 0:10

Yes, scrollbars should be visible, if for no other reason than for the sake of accessibility.

There are many instances where hiding a scroll bar makes your site/program anywhere between frustrating and borderline unusable:

  • Using assistive hardware/software to access your page
  • Using a mouse that doesn't have a scroll wheel
  • Using a remote desktop system that doesn't pass through scroll events
  • Using a touchpad that scrolls using multi-finger gestures (most average users don't know those exist)
  • Using a touchscreen, the page is more than a couple of screens tall, and I need to scroll to somewhere on the other end of the page
  • Using a touchscreen, scrolling a page that's full of links/buttons (where the tap-and-flick motion is reasonably likely to accidentally activate something)

Visible scroll bars are an easy way to avoid all of these problems. If your colleague's primary argument is that other sites are doing it, then don't even listen to him. Peer pressure is not a valid argument unless accompanied by a significant, meaningful reason why doing it is a good idea. That sort of thinking is how the <blink> tag became popular.

Also for the sake of accessibility, don't implement your own scrollbars. Use the ones provided by the system. Assistive technology can't always identify homemade scrollbars and operate them as such.


A scroll bar is extremely useful

  1. it shows the user that page is scrollable
  2. it shows the user where they are currently on the scrollable page

You have no idea how many times I was pissed and lost because some crappy designer thought that deleting the scroll bar is a good idea.


To add to MichaelS’ answer,

On tablets and iPads, a non grabable scrollbar, that hides when not scrolling, is preferable. As he said, scrolling on touch devices is much more precise, and visible, grabbable, scroll bars are clunky and annoying. However, depending on the page length, a back to top button would be welcome.

Also, whilst writing this on StackExchange using a 12.9 inch iPad pro, I noticed that adding a decent (~1cm) amount of padding, in a sligthly different tone, is helpful as it allows scrolling without accidentally opening links.

  • In my opinion, this answer is outdated as of iPadOS 13.4 (since mice are now officially supported), at least as long as the hidden scrollbars do not become visible when touching the right hand margin.
    – bjornte
    Commented Apr 8, 2020 at 7:45

An interesting question, my 2c coming from a developer but UX lead and also having designed interfaces with several internal scrollable areas.

A few points:

  1. Visible scrollbars should exist if the content is large enough to require a scroll, as the presence of a scrollbar signifies and affords that the content can be scrolled.
    • Infinite scroll is my personal idea of hell, especially if you clicked on the trackbar and are dragging it (tangent over)
  2. If the content cannot be scrolled then scrollbars are an anti-affordance suggesting things which cannot happen.
    • An edge case is things which cannot be scrolled now but might be able to if say, the content increases in size, this is common in editors, or any system with dynamic output. Specifically because if you add/remove the scroll functionality it can mess with layouts, you get some horizontal jank as the content extends and then the scrollbar appears. (if you use overflow: auto for example). In this case it can be easier to put a disabled scrollbar to indicate that this is a scrollable area, but the content isn't yet large enough to enable this behaviour.
  3. Horizontal scrollbars are normally a bad idea if combined with vertical scrollbars as it introduces and implicit mode select. As in, the default from a mouse scroll is normally vertical scroll, but with an implicit addition keypress (or trackpad interaction) horizontal scrolling can be achieved. The complexity of this is very rarely achieved.
  4. Within some application interfaces (e.g. Slippy maps) removing all scrollbars can be a good idea, as the content moves underneath the browser window in that paradigm, not the other way round. The controls are well understood by most users.
  5. Trying to style scrollbars is 99% of the time not a great idea unless you want many specific custom versions, imo accept they won't look perfect in all environments and use the browser defaults.

Is the designer talking about replacing scrollbars with a floating scroll down/up button? I think it's reasonable because that's a mobile-first approach and I've seen it being used successfully in certain contexts, but those buttons can't replace scrollbars in a grid.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.