A back to top button looks like a five minute job: a floating arrow, a bit of JavaScript, done. Then it lands on top of the live chat bubble, covers the sticky “Add to cart” bar on mobile, and traps keyboard users in a weird focus order.
This guide covers the parts most tutorials skip: when a back to top button is actually worth adding, exactly where to position it so it does not collide with other floating elements, what size it should be, and how to build one with smooth scrolling, scroll triggered visibility and proper accessibility support.
Do you actually need a back to top button?
Not every page needs one. Nielsen Norman Group’s long standing guidance is simple: the button helps on long pages, and it becomes noise on short ones. Here is a practical decision list.
Add one when
- The page is longer than roughly 3 to 4 screen heights (blog posts, documentation, long form sales pages, FAQ pages).
- The page uses infinite scroll or “load more” product grids, where users travel far from the top.
- Your primary navigation is only at the top and does not stick, so returning to the top is the only way to navigate.
- Analytics show deep scroll depth (50 percent or more of sessions reaching 75 percent of the page).
- Your audience skews toward trackpad and touchscreen users, where flick scrolling back up is tedious.
Skip it when
- The page fits in one or two viewports.
- You already have a sticky header that keeps navigation and search permanently available. In that case the button is mostly redundant, though it can still help on very long pages.
- The bottom right corner is already occupied by a chat widget, cookie bar or sticky CTA and you cannot free up space.
Rule of thumb: the button should appear only after the user has scrolled past a full viewport, and it should never be the most eye catching element on the screen.
Quick specification sheet
If you only read one section, read this table. These values work on the vast majority of sites. commoninja.com goes into the numbers.
| Property | Desktop | Mobile |
|---|---|---|
| Button size | 44 to 56 px square | 48 px minimum (tap target) |
| Icon size | 16 to 24 px arrow | 20 to 24 px arrow |
| Position | Bottom right, 24 to 32 px from edges | Bottom right, 16 px plus safe area inset |
| Trigger point | After 1 viewport height scrolled | After 1.5 to 2 viewport heights |
| Opacity at rest | 0.7 to 0.9, full on hover | Full opacity, no hover state |
| z-index | Below modals and cookie banners | Below sticky purchase bars |
Where to place a back to top button on desktop
The bottom right corner is the convention, and conventions are worth respecting. Users scan there for floating controls, and it keeps the button out of the reading column.
- Distance from edges: 24 to 32 px feels balanced. Anything under 16 px looks glued to the viewport edge.
- Avoid the content column: on wide screens the button sits in the empty gutter, which is exactly where it should be.
- Left side alternative: only use it if your right corner is permanently occupied and cannot be changed. Users will still find it, but it costs a moment of hesitation.
- Sticky footers: if you have a footer bar, position the button above it with
bottom: calc(footer-height + 16px)rather than letting them overlap.
Sharing the corner with a chat widget
Live chat launchers (Intercom, Crisp, Tawk, HubSpot and similar) almost always claim the bottom right corner with a high z-index. You have three sane options:
- Stack vertically: keep the chat bubble at the bottom and push the back to top button above it, typically
bottom: 96pxon desktop andbottom: 88pxon mobile. - Split the corners: chat on the right, back to top on the bottom left. Clean, but less conventional.
- Move the chat launcher: most chat platforms let you set a horizontal and vertical offset in their settings, which is usually the tidiest fix.
Where to place it on mobile
Mobile is where back to top buttons cause the most damage, because the screen is small and every plugin wants that same corner.
- Respect the safe area: use
env(safe-area-inset-bottom)so the button clears the home indicator on modern iPhones. - Stay clear of sticky CTAs: if you have a fixed “Add to cart”, “Book now” or “Call us” bar, the button must sit above it, never on it. Revenue elements win.
- Keep it small: 44 to 48 px is enough. Large floating circles eat reading space.
- Consider hiding it near the footer: when the user reaches the last screen, the footer usually contains navigation anyway.
- Do not stack three floating things: chat, WhatsApp icon and back to top on the same edge is a mess. Pick two at most.
Collision cheat sheet
| Element already in the corner | Recommended fix |
|---|---|
| Live chat launcher | Offset the back to top button 72 to 96 px upward |
| Sticky add to cart bar | Place the button above the bar height plus 12 px |
| Cookie consent banner | Hide the button until consent is dismissed |
| Sticky table of contents | Drop the button entirely, the TOC links to the top |
| Floating WhatsApp or call icon | Use opposite corners or merge into one action stack |
The markup: a link, not just a button
Start with an anchor pointing to a real target at the top of the document. This works even if JavaScript fails, and it gives assistive technology a meaningful destination.
<!-- Top of the page, just inside <body> -->
<span id="top" tabindex="-1"></span>
<!-- Just before </body> -->
<a href="#top" class="back-to-top" id="backToTop" aria-label="Back to top of page">
<svg viewBox="0 0 24 24" width="22" height="22" aria-hidden="true" focusable="false">
<path d="M12 5l-7 7h4v7h6v-7h4z" fill="currentColor"></path>
</svg>
</a>Two details that matter:
- The SVG is marked
aria-hidden="true"so screen readers announce only the label, not a stray graphic. - The anchor lives at the end of the DOM, which keeps it last in the natural focus order instead of interrupting the header.
The CSS: size, position and scroll triggered visibility
/* Smooth scrolling, but only for users who want motion */
@media (prefers-reduced-motion: no-preference) {
html { scroll-behavior: smooth; }
}
.back-to-top {
position: fixed;
right: 24px;
bottom: calc(24px + env(safe-area-inset-bottom, 0px));
z-index: 90; /* below modals and cookie banners */
display: inline-flex;
align-items: center;
justify-content: center;
width: 48px;
height: 48px;
border-radius: 50%;
color: #fff;
background: #1f2937;
box-shadow: 0 4px 14px rgba(0, 0, 0, .18);
text-decoration: none;
opacity: 0;
visibility: hidden;
transform: translateY(12px);
transition: opacity .25s ease, transform .25s ease, visibility .25s;
}
.back-to-top.is-visible {
opacity: .92;
visibility: visible;
transform: translateY(0);
}
.back-to-top:hover,
.back-to-top:focus-visible {
opacity: 1;
background: #111827;
}
/* Never remove the focus ring */
.back-to-top:focus-visible {
outline: 3px solid #2563eb;
outline-offset: 3px;
}
/* Mobile: smaller offsets, room for a sticky CTA bar */
@media (max-width: 640px) {
.back-to-top {
right: 16px;
bottom: calc(80px + env(safe-area-inset-bottom, 0px));
width: 44px;
height: 44px;
}
}
/* Respect reduced motion preferences */
@media (prefers-reduced-motion: reduce) {
.back-to-top { transition: none; }
}Note the use of visibility alongside opacity. An element at zero opacity is still focusable and still clickable, which creates invisible tab stops. Combining both properties removes it from the accessibility tree when hidden.
The JavaScript: efficient scroll detection
Listening to every scroll event is wasteful. Use an IntersectionObserver on a sentinel element instead. It fires only when the top of the page leaves or enters the viewport.
(function () {
var btn = document.getElementById('backToTop');
var sentinel = document.getElementById('top');
if (!btn || !sentinel) return;
// Show the button once the sentinel is one viewport above
var observer = new IntersectionObserver(function (entries) {
btn.classList.toggle('is-visible', !entries[0].isIntersecting);
}, { rootMargin: '100% 0px 0px 0px', threshold: 0 });
observer.observe(sentinel);
btn.addEventListener('click', function (e) {
e.preventDefault();
var reduce = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
window.scrollTo({ top: 0, behavior: reduce ? 'auto' : 'smooth' });
// Move focus so keyboard and screen reader users follow the jump
sentinel.focus({ preventScroll: true });
// Keep the URL clean
if (history.replaceState) {
history.replaceState(null, '', location.pathname + location.search);
}
});
})();A no JavaScript fallback
If you want zero scripting, the anchor alone already works. Combine it with a CSS only reveal using animation-timeline: scroll() in browsers that support scroll driven animations, and keep the button permanently visible elsewhere. For most production sites, the small script above is more predictable across browsers.
Accessibility checklist
This is the part that separates a professional implementation from a copy pasted snippet.
1. Focus order
Place the button last in the DOM. A fixed element positioned visually at the bottom but written at the top of the HTML confuses keyboard users, who reach it before the main content.
2. Move focus after the jump
Scrolling the viewport does not move the keyboard focus. Without focus() on a target at the top, a keyboard user presses Enter, the page scrolls, then their next Tab jumps back to the footer. Give the target tabindex="-1" so it can receive focus programmatically without becoming a tab stop.
3. Label wording
| Label | Verdict |
|---|---|
| “Back to top” | Good, short and conventional |
| “Back to top of page” | Best, unambiguous when several regions scroll |
| “Scroll to top” | Acceptable, slightly device specific |
| “Top” | Too vague out of context |
| “Up arrow” or “Click here” | Avoid, describes the icon not the action |
4. Respect prefers-reduced-motion
Long smooth scrolls across a 10,000 pixel page can trigger nausea or dizziness for people with vestibular disorders. Handle it in both places: the CSS scroll-behavior rule and the window.scrollTo call, since programmatic scrolling with behavior: 'smooth' overrides the CSS.
5. Contrast and target size
- Contrast ratio of at least 3:1 between the button and the background behind it, and 4.5:1 for any text inside.
- Minimum 24 by 24 CSS pixels to satisfy WCAG 2.2 target size, though 44 px is the comfortable standard.
- Do not lower opacity below roughly 0.8, or the contrast calculation stops passing.
6. Do not hide real content
Check the button against long tables, code blocks, image captions and video controls. A floating element sitting permanently on top of a “Next” pagination link is a genuine usability bug.
Common mistakes we see during site audits
- Always visible from the very top of the page. Useless and distracting until the user scrolls.
- An animated scroll that takes two seconds. Keep any smooth scroll under roughly 500 ms or let the browser default handle it.
- Adding
#topto the URL and polluting browser history on every click. - z-index: 9999 so the button covers modals, cookie banners and dropdown menus.
- Removing the outline for aesthetics, which makes the button invisible to keyboard users.
- Duplicate buttons from a theme option and a plugin at the same time. Check both before adding a third.
Testing checklist before you ship
- Tab to the button with the keyboard and press Enter. Does focus land at the top?
- Turn on “Reduce motion” in your operating system. Does the page jump instantly instead of gliding?
- Open the site on a phone with a sticky CTA. Any overlap?
- Open a modal, a cookie banner and the chat window. Does the button stay behind them?
- Zoom the browser to 200 percent. Does the button still clear the content?
- Test in landscape on a small phone, where vertical space is tight.
FAQ
What is a back to top button?
A back to top button is a small floating control, usually an upward arrow in the bottom right corner, that instantly returns the visitor to the top of the current page. It is a shortcut for long pages, replacing repeated scrolling or flicking.
How do I scroll back to the top with a button?
Link the button to an anchor at the top of the document (href="#top") and enhance it with window.scrollTo({ top: 0, behavior: 'smooth' }). Add a class when the user scrolls past one viewport so the button appears only when it is useful.
How do I get to the top of a page without scrolling?
On desktop, press the Home key, or Command plus the Up arrow on macOS. On most Android and iOS browsers, tapping the status bar or the address bar area jumps to the top. A back to top button simply makes that shortcut visible and discoverable for everyone else.
Should the back to top button be a link or a button element?
An anchor pointing to a real in page target is preferable, because it works without JavaScript and communicates a destination. Use a <button> only if the action is purely scripted and there is no anchor target available. It is argued more carefully on w3schools.com.
Does a back to top button affect SEO?
Not directly. It has no ranking signal of its own, but it influences engagement metrics on long pages, and a badly placed one that covers content or hurts Core Web Vitals through heavy scripting can cause indirect harm. Keep it lightweight and non intrusive.
Where should the button be on mobile?
Bottom right, 16 px from the edge, offset upward to clear the home indicator and any sticky call to action bar. If a chat launcher already owns that corner, either stack the button above it or move the launcher in its settings. The topic gets a thorough treatment elsewhere.
Do I still need one if my header is sticky?
Usually not, since navigation stays reachable. On extremely long pages such as documentation or endless product grids, a back to top button still saves time, so judge it by page length rather than by rule.
Need help getting the details right?
Small interface elements like this one are where usability quietly leaks away. If you want a site where the navigation, floating widgets and calls to action work together instead of fighting for the same corner, the team at FatCow Web Design can audit your current build or design it properly from the start.
