Hamburger menu icon: should it be on the left or right?

Quick answer: put the hamburger menu where its panel opens. In native apps with a side drawer or sidebar, that is the top left, because Apple and Android both place the sidebar on the leading edge. On responsive websites, where the logo usually takes the top left, the top right is the common and perfectly usable choice, and it is easier to reach with a right thumb. Better still, if you only have four or five main sections, skip the hamburger and show them in a bottom tab bar.

Updated October 2026. Since this was written, most major apps have moved primary navigation to a bottom tab bar on mobile; the hamburger icon now mostly holds secondary items. The left-versus-right arguments below still apply to whichever items remain in it.

The hamburger menu icon is one of the most ubiquitous icons on the web. It is usually used to indicate a menu bar, and it is often placed in the top-left corner of the screen. But there is some debate over whether the hamburger menu icon should be on the left or right side of the screen.

Brief History

The hamburger menu icon was first introduced in the early days of the web (when we did not design for mobile screens), and it was usually placed in the top-left corner of the screen. This was because the top-left corner was the traditional location for the menu bar. But over time, the hamburger menu icon has been used in other locations, including the top-right corner of the screen.

It is worth separating it from its cousins before going further. Three stacked lines open site or app navigation; three vertical dots (a kebab) open actions for one item; see hamburger vs kebab menus if you are not sure which one you need, and icon vs icon with text vs just text for whether the icon should carry a "Menu" label.

Left-Side Placement

There are several arguments for why the hamburger menu icon should be placed on the left side of the screen. The first argument is that the left side is the traditional location for the menu bar. The second argument is that the left side is the location of the primary content area.

Native apps with a sidebar or drawer

Native apps are where the left is clearly right. Apple’s guidelines describe a sidebar as something that “appears on the leading side of a view”, which is the left in left-to-right languages, so a menu button that opens it belongs on the left too. Android’s equivalent, Material’s navigation drawer, follows the same convention. Putting the button next to the edge the panel slides in from keeps cause and effect in one place, which is the same principle behind a good dropdown affordance: the control should hint at what it opens and where.

Desktop and wide layouts

On wide screens the question changes: there is room to show navigation, so you usually should. Nielsen Norman Group’s guidance on left-side vertical navigation is that it suits broad or growing information architectures, provided it is left-aligned, keyword front-loaded and visible. Eye-tracking backs up the left edge too: in the F-shaped reading pattern, fixations concentrate at the top and the left of the page, and people inspect navigation bars “typically at the top and/or left of the page” to decide where to go next. If you still use a hamburger on desktop, the top left is where people will look for it, a habit Jakob’s law predicts: users expect your site to work like the sites they already know, and their mental model of where navigation lives was built on those sites. Breaking that convention needs a good reason; “consistency and standards” is one of the ten usability heuristics for exactly this case.

Right-Side Placement

There are several arguments for why the hamburger menu icon should be placed on the right side of the screen. The first argument is that the right side is the traditional location for the main navigation menu. The second argument is that the right side is the location of the main action buttons, such as the “submit” button – although I personally do not like it. The third argument is that the right side is the location of the global navigation menu.

So, which side is the best location for the hamburger menu icon? There is no definitive answer, and it depends on the specific website or app. However, the general consensus seems to be that the hamburger menu icon should be placed on the right side of the screen for most responsive websites.

Responsive websites where the logo owns the top left

On most responsive sites the logo already sits in the top left and links home. Stacking the menu button on the same corner crowds two different jobs into one spot, so the menu moves to the top right, where it also lines up with the desktop navigation it replaces. Whatever you choose, keep the header simple: a logo, the menu and at most one action. Minimalistic layouts work on small screens because every element in that header competes for the same few hundred pixels; check yours at the smallest screen size you design for and at today’s most common screen resolutions.

Thumb reach on large phones

On mobile screens, you must put it on the top-right if the menu icon must go on top. Otherwise, the best alternative is to not have it on the top at all. This is because the top part of the screen is not reachable by the thumb on most devices, making it difficult or impossible for users to access the menu.

The numbers behind that are older than most of today’s phones, and phones have only grown since. Steven Hoober’s 1,333 observations of people using phones found 49% using the phone one-handed, 36% cradling it, and 15% holding it in both hands. That research is where the idea of a thumb zone comes from: the top corners are the hardest to reach one-handed, and the top left is the worst for a right-handed user. Fitts’s law adds the rest: small targets far from where the thumb rests take longer to hit and get missed more often, which is also why button size on touch screens matters as much as position.

Mixed or Dynamic Placement

The more useful question is often not left or right, but whether the menu should be hidden at all, and many products now split navigation between a visible bar and a menu.

Bottom tab bars plus a menu for everything else

Nielsen Norman Group tested hidden, visible and combination navigation on real sites. Hiding the navigation cut content discoverability by more than 20%, and on mobile, people used the navigation in 57% of tasks when it was hidden behind a hamburger versus 86% when some of it stayed visible. Their advice: never hide navigation on desktop, and on mobile show it when you have four or fewer top-level links. Their primer on mobile navigation patterns frames the trade-off well: navigation must be discoverable and accessible while taking little screen space, and every pattern sacrifices one of the two.

Luke Wroblewski’s “Obvious Always Wins” collects what happened when teams changed it in production. When the Polar app moved its sections behind a toggle menu to look “cleaner”, engagement plummeted; when Facebook moved its iOS app from a hamburger to a bottom tab bar, engagement went up, along with several other important metrics.

Apple’s tab bar guidance makes the same point from the other side: keep the tab bar visible as people move around the app, because “if you hide the tab bar, people can forget which area of the app they’re in.” Material’s navigation bar is the Android equivalent.

Hamburger menu vs bottom tab bar on mobile

Aspect	Hamburger menu	Bottom tab bar
Best for	Many destinations, or secondary items (settings, help, legal)	3 to 5 main sections people switch between often
Visibility	Hidden until tapped	Always on screen
Thumb reach	Poor at the top of a large phone	Good, it sits where the thumb already is
Shows where you are	Only when opened	Yes, the active tab is highlighted
Room to grow	Plenty	Tight; extra items end up behind a More tab

Most well-known apps now combine the two: a tab bar for the main sections and a menu or profile screen for everything else. That is progressive disclosure applied to navigation: the frequent destinations stay visible and the rare ones wait one tap away. Long pages need the same care; if the page itself scrolls forever, see infinite scrolling best practice and how to show users they can scroll so the menu is not the only way people find their way around.

Right-to-left languages and dynamic layouts

In right-to-left languages such as Arabic and Hebrew, mirror all of this: the leading edge is on the right, so a menu that opens a sidebar moves to the top right and everything else flips with it. Apple’s right-to-left guidance and Material’s bidirectionality guide cover which elements flip and which do not. Some sites also move the menu depending on breakpoint or scroll, for example collapsing a visible desktop nav into a hamburger on small screens or revealing a sticky header on scroll up. That is fine as long as the button lands in the same place every time it appears; a menu that changes corners between pages is a different control on every page.

Accessibility and Cognitive Load

Wherever the icon goes, the bigger usability wins usually come from how it is built and how much it asks people to remember.

Make the button a real, labelled control

Three lines are not a name. Use a real <button> with an accessible name such as “Menu”, and expose whether it is open, which is what WCAG’s name, role, value requirement asks for. The W3C’s disclosure navigation menu example shows the pattern, including aria-expanded. Size matters for everyone with less precise fingers: WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels, and the platform guidelines ask for more on touch screens. Hover-only menus fail on phones entirely; our guide to alternatives to hover on touchscreens covers what to do instead, and whether users should be able to zoom is worth reading before you lock the viewport around a fixed header. A visible text label next to the icon also helps the signifier do its job for people who do not recognise three lines as a menu, and keeps the button’s affordance obvious. Once open, a full-screen menu behaves like an overlay: give it a clear way out and handle focus the way you would for modals, popovers and lightboxes, with a close control that does one job (see whether a close button and an X are redundant).

Keep it in the same place and the list short

Navigation that moves costs memory. WCAG’s consistent navigation criterion asks that repeated navigation appears in the same relative order on every page, and the same logic applies to the button itself. Inside the menu, keep the list short and ordered by importance: Hick’s law says decision time grows with the number of choices, the serial position effect says the first and last items are remembered best, and recognition over recall is the case for showing the main sections rather than asking people to remember what hides behind an icon. Nielsen Norman Group’s menu design checklist adds the step teams most often skip: indicate the user’s current location in the menu. All of this is about minimising cognitive load; our glossary entry on cognitive load has the short version.

Test with Users

The best way to decide where to place the hamburger menu icon is to test it with users. Try out different locations and see which one is the most user-friendly. You may also want to test different icon designs, as users may have different opinions on which design is the most user-friendly. Watch for rage clicks on the header and for people who never open the menu at all; both tell you more than a preference survey. Our prototype testing tool comparison covers tools that can measure several success paths through a menu, and the free UX audit and its checklist catch the accessibility basics above on a live site.