Most mobile apps have moved their primary destinations into a visible tab bar, yet the hamburger icon is still everywhere: on marketing sites, in desktop dashboards, and as the overflow for everything that did not earn a tab. The question is no longer whether the pattern is good or bad but what belongs behind it. A hamburger menu is the right home for navigation people seek out and the wrong one for navigation they need to discover.
In this glossary topic:
What is a hamburger menu?
A hamburger menu is a UI control consisting of 3 horizontal lines stacked vertically, typically placed in a corner of the interface. Tapping or clicking it opens a navigation drawer, a side panel, or a menu overlay containing links to different sections of the product. The icon's name comes from its resemblance to a hamburger in cross-section: two buns and a patty.
The pattern emerged as a space-saving solution in the early days of mobile design, when small screens created pressure to minimize on-screen interface elements. By hiding navigation behind a single icon, designers could keep the primary content area clear while technically providing access to all navigation options.
The hamburger menu became ubiquitous across mobile applications and websites in the early 2010s. It also became one of the most studied and debated patterns in UX research, producing a consistent body of evidence about where it works, where it doesn't, and what typically performs better.
What does the research say about hamburger menus?
The evidence against using hamburger menus for primary navigation in mobile apps is substantial and has shaped how most major consumer applications are built today.
Hidden navigation is less used than visible navigation. When options are hidden behind a hamburger icon, users tap into them less frequently than they would if those same options were visible. This is not a user failure: it's the predictable consequence of additional interaction steps and reduced discoverability. Users who don't open the menu don't know what they're missing.
The two-tap penalty compounds over sessions. Every destination that requires opening the hamburger menu first costs an extra tap compared to a visible tab bar. For users who navigate between sections frequently, this adds up. Research from several mobile usability studies shows navigation is faster with visible bottom navigation compared to hamburger menus.[1]
The case studies are telling. Facebook and Google both moved away from hamburger menus as primary navigation in their mobile apps after usability research showed that features hidden in the menu received less engagement.
When does the hamburger menu work well?
The pattern is not universally harmful. Context determines whether it's appropriate.
- Hamburger menus work well for secondary navigation: settings, account management, less-frequently used features, and administrative functions that users access occasionally but don't need constant access to. Hiding these in a hamburger menu keeps the primary navigation clean without meaningfully harming discoverability for content that users actively seek out.
- They work well on desktop interfaces where screen space is less constrained and users have more screen real estate but may still want a way to access a large number of navigation options without a complex top navigation structure. News sites, content platforms, and dashboards with many sections often use hamburger menus effectively on desktop.
- They work well in applications with very large navigation sets, where the number of destinations exceeds what a tab bar can accommodate. An enterprise application with twelve primary sections cannot fit them all in a bottom navigation bar, and a hamburger menu that provides access to all of them is more appropriate than forcing an artificial prioritization.
- They work for navigation that users access intentionally and deliberately, rather than navigation they're expected to use to discover features or content. If the menu contains things users look for rather than things they need to stumble across, discoverability is less of a concern.
What are the main alternatives?
The alternatives to hamburger menus are navigation patterns that make primary destinations visible rather than hidden.
- Bottom tab bars are the most commonly recommended replacement for primary mobile navigation, placing 3-5 top-level destinations as permanently visible, tappable items at the bottom of the screen. They follow Apple's HIG and Material Design guidance, are reachable with one tap from anywhere in the app, and keep the navigation structure visible to users at all times.
- Top tab bars appear at the top of the screen and work well for switching between peer-level sections within a feature rather than between top-level areas of an app. They're more common on Android than iOS and are well-suited for switching between filtered views or content categories.
- Navigation drawers (the panel that a hamburger menu typically opens) can be kept useful as a complement to a bottom tab bar, containing overflow navigation that isn't prominent enough for a tab bar slot. This hybrid approach gives frequently used destinations bottom bar placement while keeping less-used options accessible without cluttering the primary navigation.
- Full-screen navigation, sometimes called a "mega menu" on desktop, presents all navigation options in an overlay that fills the screen when triggered. It makes all options visible simultaneously, which can reduce the discoverability problem, though it requires a full-screen interruption to access.
What does a hamburger menu look like in practice?
The pattern has two states, and the icon is only the first of them. Everything the menu hides is one tap away, and nothing in the closed state tells the user what is behind it.
The closed and open states side by side: the 3-line icon sits in the top left corner, and tapping it slides out a navigation drawer titled "Delivery" with Offers & Promos, Privacy Policy, and Support, none of which is visible until the menu opens. From the lesson Common Navigation Patterns.
How should hamburger menus be designed accessibly?
When hamburger menus are used, several accessibility requirements apply.
- The icon alone is insufficient for many users. Adding a visible text label "Menu" alongside the 3-line icon makes the control's purpose clear for users who don't recognize the icon convention, which is more common among less tech-savvy users and in global markets. Screen readers need an accessible name on the button; an icon with no text and no accessible label is announced as an unlabeled button.
- Touch target size must meet minimums: 44x44 points on iOS and 48x48dp on Android. The 3-line icon is visually small, and if the interactive area isn't extended through padding, the tap target may be smaller than these minimums.
- When the menu opens, focus must move into the menu content so keyboard and screen reader users don't continue navigating the background content. When the menu closes, focus should return to the hamburger button. The open/closed state of the menu should be communicated programmatically using
aria-expandedon the button, so screen reader users know whether the menu is currently open. - Transitions should be smooth and not disorienting. The animation for opening and closing the navigation drawer should be fast enough to feel responsive and should respect the user's reduced-motion system preference.
