Bottom navigation is a mobile UX pattern in which a persistent bar at the bottom of the screen holds three to five top-level destinations of an app, each shown as an icon with a short label. A tap switches instantly between these sections, and the bar stays visible on all of them, so users always know where they are and where they can go.
In mobile design the pattern exists because of how phones are held. The lower part of a tall screen is the area most easily reached by the thumb, so placing primary navigation there reduces stretching and makes one-handed use practical. Android calls the component a navigation bar in Material Design, while iOS calls it a tab bar.
How bottom navigation works
Each item in bottom navigation represents a parallel top-level section, not an action. Tapping an item shows that section’s root screen, and the selected item is marked by color, a filled icon or an active indicator shape. The bar is usually hidden only on full-screen tasks such as composing a message or viewing media.
A key design decision is how each section keeps its navigation history. On iOS, each tab traditionally keeps its own stack, so leaving and returning restores the screen the user left. Tapping the active tab again typically scrolls to the top or pops back to the root of that section.
The table lists the main behaviors that define a well-built bar.
| Behavior | Expected result | Why it matters |
|---|---|---|
| Tap on inactive item | Show that section, keep its state | Fast switching without losing work |
| Tap on active item | Scroll to top or return to section root | Quick reset inside a section |
| System back gesture | Go back within the section, then exit | Predictable behavior on Android |
| Badge on item | Dot or count for new content | Draws attention without interrupting |
| Hide on scroll | Optional, bar returns on upward scroll | More content space on small screens |
Dimensions, item count and platform guidelines
Bottom navigation works within narrow numeric limits. Fewer than three destinations do not justify a permanent bar, and more than five make targets too small and labels hard to read. Destinations beyond five usually move into a More tab or a separate screen.
| Parameter | Typical value | Note |
|---|---|---|
| Number of destinations | 3 to 5 | More items reduce target width and clarity |
| Bar height on Android | About 80 dp in Material 3 | Earlier Material versions used 56 dp |
| Bar height on iOS | About 49 pt plus safe area | Home indicator area adds extra space |
| Minimum touch target | 44 pt on iOS, 48 dp on Android | Platform accessibility guidance |
| Label length | One short word if possible | Long labels truncate or wrap |
The bar must respect the safe area at the bottom of modern phones, where the home indicator or gesture handle sits. Content inside the bar is padded above that region, while the bar background usually extends to the screen edge so it looks continuous. Ignoring this produces icons that collide with the system gesture area.
Bottom navigation compared with other navigation patterns
Bottom navigation is one of several ways to expose top-level structure. Its main advantage over a hamburger menu is visibility: destinations that are always on screen are discovered and used more often than items hidden behind an icon.
| Pattern | Best for | Main drawback |
|---|---|---|
| Bottom navigation | 3 to 5 frequently used sections | Takes permanent vertical space |
| Navigation drawer | Many sections or rarely used areas | Hidden items are discovered less often |
| Top tabs | Related views within one section | Hard to reach with the thumb |
| Navigation rail | Tablets and wide screens | Not suited to narrow phone widths |
| Gesture navigation | System back and home actions | Gestures are invisible and must be learned |
In an adaptive layout, the same destinations often move between components as the window grows: a bottom bar on a phone, a navigation rail on a tablet or unfolded foldable, and a permanent drawer on large screens. Keeping the same destinations and order across these forms keeps the app familiar.
Designing a bottom navigation bar
Good bottom navigation starts with information architecture, not icons. The team should choose destinations by frequency of use and importance, then order them by priority, typically placing the home or main feed first on the left.
- Use nouns for destinations, such as Home, Search, Orders and Profile, not verbs.
- Always show labels unless every icon is universally understood; icon-only bars are harder to learn.
- Keep actions out of the bar; a create action belongs in a floating button or top bar.
- Ensure color contrast of at least 3:1 for icons and 4.5:1 for small label text.
- Expose accessibility roles so screen readers announce each item as a tab with its selected state.
Teams should test the bar with real usage data. If analytics show that one destination is rarely opened, it may belong in a secondary menu, freeing space and reducing decision load in the primary bar.
Common mistakes with bottom navigation
Most problems arise when the bar is used for purposes it was not designed for, or when platform conventions are ignored.
| Mistake | Effect on users | Correction |
|---|---|---|
| Six or more items | Crowded bar, small targets | Group items or add a More section |
| Resetting tab state | Lost scroll position and input | Keep a separate stack per tab |
| Mixing actions and destinations | Unclear meaning of items | Move actions to buttons or menus |
| Ignoring the safe area | Icons overlap the home indicator | Apply bottom insets correctly |
| Bar visible on every screen | Distraction during focused tasks | Hide it on full-screen flows |
The simple explanation
Bottom navigation is the row of icons along the bottom of many apps. Each icon leads to one main part of the app, such as the home feed, search or your profile.
It sits at the bottom because that is where your thumb naturally rests when you hold a phone in one hand. It works like the tabs on a paper folder. You can always see every section, and one tap takes you straight there without getting lost.
How it is used in practice
A food delivery app originally hid its sections in a side drawer menu. Usage data showed that many customers never found the order history, so they contacted support to check delivery status. The design team replaced the drawer with four bottom navigation items: Home, Search, Orders and Account.
Each tab keeps its own history, so a customer who checks an order and returns to Search finds the previous results intact. Labels stay visible, and the Orders item shows a badge while a delivery is active. After the release, the team saw fewer support contacts about order status and more visits to the Orders section, a direct result of making a key destination permanently visible.