Bottom navigation on mobile websites: when a tab bar fits, and its pitfalls
A bottom navigation bar suits mobile websites that behave like apps: a few top-level sections people switch between often, such as a dashboard, a tracker or a booking tool. For a brochure site with a long scrolling home page, it mostly takes up space. If you use one, keep it to three to five labelled items and design around the browser's own toolbar.
Where the pattern comes from
Tab bars along the bottom of the screen became standard in phone apps because that's where thumbs rest. Switching between a handful of main sections, such as Home, Search and Account, is one tap from anywhere, and the bar shows where you are. Websites borrowed the idea as more of them started to behave like apps, especially sites people add to their home screen and open daily.
The difference is that an app owns the whole screen, while a website shares it with a browser. That shared space is where most of the problems below come from.
When a bottom bar earns its space
| Kind of site | Bottom bar? | Reason |
|---|---|---|
| Tracker, planner or dashboard used daily | Good fit | People jump between a few views many times per visit |
| Installed web app opened from the home screen | Good fit | There's no browser toolbar competing for the bottom edge |
| Shop with search, basket and account | Possible | Works if the bar stays to four items and doesn't cover the buy button |
| Brochure site or portfolio | Rarely | Visitors scroll one page and leave; a header link and a clear call to action do more |
| Article or blog | No | Reading needs every pixel of height |
Rules for the bar itself
- Three to five destinations. Fewer, and a bar isn't needed; more, and labels get cramped. Put the rest in a "More" view.
- Destinations, not actions. Each item takes you to a section. "New entry" or "Share" belong in the content or a separate button.
- An icon and a word for every item. Icons alone are guessed at. Short labels such as "Today", "History", "Settings" make the bar readable.
- A clear current state that doesn't rely on colour alone: a filled icon, a bar or bold label, with
aria-current="page"in the markup. - Large targets. Divide the width evenly and make each item at least 44px tall, so a thumb can't hit the neighbour. See thumb zone design.
- A real nav element with a label, so screen reader users can find it among the page's landmarks.
Browser chrome and other pitfalls
Mobile browsers move their address bar and toolbar as people scroll, and some put the toolbar at the bottom. A bar pinned with position: fixed; bottom: 0 can end up stacked on top of the browser's own controls, or briefly covered by them.
- Safe areas. Phones without a home button reserve a strip at the bottom. Pad the bar with
env(safe-area-inset-bottom), as MDN's env() reference shows for a sticky footer, so icons don't sit under the home indicator. The inset is only reported when the viewport meta tag includesviewport-fit=cover. - Viewport height. Layouts sized with
100vhcan extend behind the toolbar. MDN's CSS length reference explains the small, large and dynamic viewport units (svh,lvh,dvh) that account for it; see also 100vh on mobile. - Content hidden underneath. Add bottom padding to the page equal to the bar's height, or the last line of content and the footer will sit behind it.
- The keyboard. When someone types into a field, a fixed bar can ride up above the keyboard and cover the input. Hide it while a text field has focus, or keep forms in views without the bar.
- Two bottom bars. A cookie notice or a sticky "Book now" button on top of a tab bar leaves very little page.
Bottom navigation vs the hamburger menu
The two solve different problems. A bottom bar shows a few frequent destinations all the time; a menu button tucks away a longer list people need now and then. Many app-like sites use both: a bar for the four main views and a menu for settings, help and legal pages. On wide screens, move the same destinations into a sidebar or a top bar, because a strip along the bottom of a laptop screen is far from where the cursor usually is. Hamburger menu best practices covers the menu side.
How this fits Anticode
Bottom navigation is a pattern for app builds. When you describe a tracker, planner or tool, Anticode's model writes the whole app as one program, and you can ask for a bottom tab bar with named sections; the self-review, when available, opens new app builds at phone and laptop widths so problems like a bar covering content are more likely to be caught. Every published site, app builds included, can be installed on a phone as a PWA, which is where a bottom bar feels most at home, because no browser toolbar is competing for the edge.
Pages from the design engine, such as landing pages, shops and portfolios, use a header with links instead, which suits sites people scroll through once.
Questions people ask
How many items should a bottom nav bar have?
Three to five. With more, labels shrink and targets get too small; move extra destinations into a More view or a menu.
Why is my bottom nav bar hidden behind the browser toolbar?
Mobile browsers resize the visible area as their toolbars appear and hide. Pad the bar with the safe-area inset and size full-height layouts with svh or dvh units.
Should a website use a bottom navigation bar?
Only if it behaves like an app, with a few sections people switch between often. Most brochure sites are better served by a simple header.
Sources
- env(), MDN Web Docs, checked
- <length>, MDN Web Docs, checked