Smooth scrolling means two completely different things, and the confusion between them is why the advice around it is contradictory. One is a CSS property that makes anchor jumps animate. The other is a library that replaces native scrolling entirely with an interpolated transform. The first is free and uncontroversial; the second is a real trade with real costs.
The free one
scroll-behavior: smooth on the root element makes in-page anchor navigation animate instead of jumping. That is the whole feature, it costs nothing, and it should be wrapped in a reduced-motion query:
Pair it with scroll-margin-top on your headings so a target does not land under a sticky header, which the floating navbar guide covers.
That is the version most projects want when they say smooth scrolling.
The expensive one
A smooth-scrolling library intercepts the wheel and touch events, prevents the native scroll, and moves the page with a transform toward a lerped target position. Everything on the page then moves under the library's control rather than the browser's.
What you get is real: a heavier, more cinematic feel on a trackpad, and a scroll position that scroll-driven effects can read with sub-pixel precision, which is why these libraries travel with the effects in the scroll animation guide.
What you give up is also real, and it is a longer list than most articles admit.
The mouse wheel. What feels luxurious on a trackpad often feels laggy and disconnected on a wheel, because a wheel is discrete and the interpolation smears it.
Keyboard scrolling. Page Down, Space and Home have to be reimplemented or they fight the library.
Find-in-page. The browser scrolls to a match natively; a transformed page may not follow.
Accessibility tooling. Anything that scrolls an element into view assumes native scrolling.
Anchor links, scroll restoration and position: sticky all need the library's own equivalents.
How to decide
Three questions, and if any answer is no, use the CSS property instead.
Is the scroll experience part of the product's argument, as on an agency site or a launch page? Will someone test it with a mouse wheel, with Page Down and with a screen reader before it ships? And is there a reduced-motion path that disables it entirely rather than shortening it?
That last one matters more than it sounds: for readers with vestibular sensitivity, momentum scrolling is exactly the kind of motion the preference exists to remove.
The components in this family
Smooth Scroll Hero by Shamsu Musthafa is the calm version where parallax does the work and nothing resizes. Sticky Scroll by UI Layouts is the pinned-section pattern, and Full Screen Scroll FX by scott clayton is the full slideshow.
Scroll media expansion hero by Arunachalam and Container Scroll Animation by Manu Arora are the two most-taken scroll-driven components in the catalogue, and neither requires a smooth-scrolling library to work.
That is the useful point to end on: the effects people install these libraries for mostly do not need them. CSS scroll-driven animations and an IntersectionObserver cover reveals, pinning and progress natively, off the main thread, with none of the trade-offs above.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
scroll-behavior: smooth | Animated anchor jumps, free and safe | Not momentum scrolling |
| CSS scroll-driven animations | Reveals and progress with no library at all | Uneven support; needs a fallback |
| A smooth-scrolling library | A cinematic feel and precise scroll values | Wheel, keyboard, find-in-page and sticky all become yours |
| 21st | Scroll-driven heroes and pinned sections | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Browse scroll animation components →
Frequently asked
- What is the difference between scroll-behavior and a smooth scrolling library?
- scroll-behavior: smooth animates anchor jumps and costs nothing. A library intercepts wheel and touch events, prevents native scrolling and moves the page with an interpolated transform, which changes how every scroll on the page works.
- What does a smooth scrolling library cost?
- Mouse wheel feel, since interpolation smears discrete wheel events; keyboard scrolling, which has to be reimplemented; find-in-page, which may not follow a transformed page; and anything that scrolls an element into view. Anchor links, scroll restoration and sticky positioning all need the library's own equivalents.
- When is momentum scrolling worth it?
- When the scroll experience is part of the product's argument, when someone will test it with a wheel, with Page Down and with a screen reader, and when there is a reduced-motion path that disables it entirely rather than shortening it.
- Do scroll-driven effects need a smooth scrolling library?
- Usually not. CSS scroll-driven animations and an IntersectionObserver cover reveals, pinning and progress natively and off the main thread, and the most-taken scroll-driven components in the catalogue work without one.