What Is a Drawer in UI? A Quick Guide

Every time you tap a hamburger icon and a panel slides in from the side of your screen, you’re using a drawer. It’s one of the most common UI components in modern apps and websites, yet most people couldn’t tell you what is a drawer in UI or why it works the way it does.

Drawers show up everywhere. Navigation menus on Android apps, shopping cart panels on e-commerce stores, filter sidebars on mobile. They solve a real problem: giving users access to secondary content without leaving the current view.

This guide covers how drawers are structured, when to use them instead of modals or new pages, how they behave across screen sizes, and what accessibility requirements they need to meet.

What Is a Drawer in UI

A drawer is a panel that slides in from the edge of your screen. It stays hidden until someone triggers it, usually by tapping a button or swiping from the side.

Think of it as a container that lives off-screen. Left, right, top, bottom. When activated, it glides into view and either overlaps the existing content or pushes it aside.

You’ve probably used one today without thinking about it. Gmail’s left panel on mobile? That’s a drawer. The filter sidebar on Amazon’s app? Also a drawer. The shopping cart that slides out on a Shopify store? Same thing.

The pattern goes by several names depending on context. Side panel, slide-out panel, off-canvas menu, sidebar navigation. They all describe the same core behavior: a surface that enters from a screen edge, serves a specific purpose, and can be dismissed.

What makes a drawer different from a modal? Modals sit in the center of the screen and demand full attention. They block everything behind them. A drawer, on the other hand, maintains a spatial connection to the main content. Users can still see part of the page they came from, which gives them context.

Material Design, Google’s design system, popularized the navigation drawer as a standard component in Android apps. Apple’s Human Interface Guidelines take a different approach, favoring tab bars for primary navigation instead.

Both platforms agree on one thing, though. Drawers work best as secondary access points or contextual panels, not as the only way to get around an app.

Common Types of UI Drawers

Not all drawers do the same job. The type you pick depends entirely on what the drawer needs to hold and how often users interact with it.

Navigation Drawers

This is the one most people picture first. A hamburger menu icon sits in the top corner, and tapping it reveals a list of app sections.

Android apps use this pattern more than iOS apps. Google built it directly into Material Design, and for years it was the default way to handle navigation on mobile screens. Gmail, Google Drive, Spotify (before their 2016 redesign) all used it.

Nielsen Norman Group ran a quantitative study with 179 participants across 6 websites and found that hidden navigation was used in only 27% of cases on desktop, compared to 48% for visible navigation. On mobile, hidden navigation usage sat at 57%, while combo navigation (partially visible) hit 86%.

The takeaway? Navigation drawers work on mobile when screen space is tight. On desktop, they cost you discoverability.

Contextual and Detail Drawers

Inspector panels. Properties panels. Detail views. These drawers slide in to show supplementary information about something the user already selected.

Figma uses a right-side drawer for design properties. Google Sheets opens a side panel when you insert a chart or use the Explore feature. Notion’s page properties panel works the same way.

The key trait: these drawers don’t replace the main view. They add to it. Users keep their primary content visible while reviewing or editing details alongside it.

Action-Based Drawers

E-commerce made this one famous. You click “Add to Cart” and a drawer slides out from the right showing your bag contents. No full page reload. No losing your place in the product catalog.

Shopify stores use cart drawers heavily. The global average add-to-cart rate across e-commerce sits around 5.94% as of late 2024 (Oberlo), and keeping users on the product page instead of redirecting them to a cart page reduces friction in that funnel.

Filter drawers are another action-based variant. On Amazon’s mobile app, tapping “Filter” opens a full-height drawer where you narrow results by price, rating, brand. Airbnb does the same with its search filters.

When to Use a Drawer Instead of a Modal or New Page

This is where a lot of teams get it wrong. They default to a drawer because it “feels modern” without asking whether a drawer is actually the right pattern.

Here’s a straightforward way to think about it.

Use a drawer when:

• The user needs to reference the main page while interacting with the panel
• The task is secondary or supplementary (filters, settings, quick edits)
• The content doesn’t require full user focus
• You want to avoid a full page transition for something lightweight

Use a modal when:

• The action requires confirmation or focused input (delete confirmations, payment forms)
• You need to block interaction with the background content
• The task is quick and self-contained

Use a new page when:

• The content is complex enough to deserve its own URL
• Users might want to bookmark or share it
• The information needs its own layout structure

Took me a while to internalize this, but the real question is always: does the user need to see the original content while working in this new surface? If yes, drawer. If no, modal or page.

Statcounter data from Q4 2024 shows mobile devices generated 62.54% of global website traffic. That matters because drawers on mobile eat up most of the viewport, which effectively turns them into full-screen overlays anyway. At that point, the spatial benefit of a drawer disappears.

Drawer Anatomy and Structure

Every well-built drawer has the same structural bones, regardless of the framework or component library you’re using.

Header Area

The top section. It holds the drawer title, a close button (usually an X icon), and sometimes a back arrow for multi-level navigation.

Material Design 3 specifies that the header should include a headline text and optionally a leading icon. The close action should always be accessible via the Escape key, not just the visible button.

Body and Content Area

This is where the actual content lives. Navigation links, form fields, product details, filter options, whatever the drawer is built for.

Scrollable by default. If the content exceeds the drawer’s height, this section scrolls independently from the page behind it. The header and footer stay fixed.

One thing I see developers mess up constantly: they let the body content determine the drawer height on mobile, which creates these half-open drawers that look broken. Set a consistent height or use a max-height constraint.

Footer Area

Not every drawer needs this, but it’s common in action-based drawers. A Shopify cart drawer has “View Cart” and “Checkout” buttons pinned to the bottom. A filter drawer might have “Apply” and “Clear All” at the bottom.

These call-to-action buttons stay visible regardless of scroll position in the body. That matters for usability.

Overlay and Scrim

Temporary drawers use a semi-transparent backdrop (called a “scrim” in Material Design terminology) behind the panel.

The scrim serves two purposes: it visually separates the drawer from background content, and it provides a tap target for dismissal. Users can close the drawer by clicking anywhere on the darkened area.

Material Design places the scrim at a resting elevation of 16dp behind the drawer. Persistent drawers skip the scrim entirely because they sit at the same elevation as the main content.

Drawer Behavior on Mobile vs. Desktop

The same drawer pattern behaves very differently depending on screen size. What works on a 1440px desktop monitor doesn’t automatically translate to a 390px phone screen.

Mobile Drawer Patterns

On phones, drawers almost always overlay the content. The panel slides in and covers most or all of the screen width.

Material Design recommends a maximum width of 280dp on mobile (calculated by multiplying the standard 56dp increment by five). But in practice, many apps let navigation drawers go wider, especially when the content demands it.

Touch gestures change the interaction model. Swiping from the left edge to open a navigation drawer is a standard Android pattern. iOS doesn’t have an equivalent system-level gesture for drawers, which is one reason Apple discourages this pattern.

Bottom sheets are technically a drawer variant. Google Maps uses one. Apple Maps uses one. They slide up from the bottom of the screen and are thumb-friendly in a way that top-anchored drawers aren’t.

MUI’s SwipeableDrawer component accounts for iOS specifically. Their docs note that iOS’s “swipe to go back” gesture conflicts with the drawer’s swipe-to-open behavior, so they disable the discovery feature on Apple devices.

Desktop and Responsive Drawer Behavior

Desktop gives you more room to work with, and the drawer pattern shifts accordingly.

Three variants are common on larger screens:

• Temporary: Same as mobile. Overlays content, uses a scrim, dismissed on selection. Used when screen width is limited or the drawer is used infrequently.
• Persistent: Toggles open and closed. Sits at the same elevation as content and pushes the layout when open. The state carries over between sessions.
• Permanent: Always visible. Pinned to the left edge. Cannot be closed. Recommended by Material Design for desktop apps focused on information consumption.

Responsive design typically switches between these variants at specific breakpoints. Material Design suggests converting a temporary drawer to a permanent sidebar around 1280dp and wider.

Gmail does this well. On a small tablet, you get a temporary overlay drawer. On a desktop browser, the drawer is permanent, always showing your folder list on the left side.

Accessibility Requirements for Drawers

The WebAIM Million 2025 report found that 94.8% of the top one million homepages still had detectable WCAG failures. Drawers are one of the trickiest components to get right from an accessibility standpoint.

Focus Management

When a temporary drawer opens, keyboard focus must move inside it. This is called focus trapping.

Without it, a screen reader user or keyboard-only user can Tab right past the drawer and interact with content behind the overlay. That breaks the experience completely.

When the drawer closes, focus should return to the element that triggered it. If a user clicked “Open Menu” and then closed the drawer, focus goes back to that button.

Keyboard Navigation

Escape key closes the drawer. Tab cycles through interactive elements inside it. Shift+Tab moves backward.

These aren’t optional extras. The ARIA authoring practices specify this behavior for dialog-type components, and a temporary drawer functions as a dialog.

ARIA Roles and Attributes

A temporary drawer that overlays content needs role="dialog" and aria-modal="true" on its container.

Add aria-label or aria-labelledby to give the drawer an accessible name. Something like “Navigation menu” or “Shopping cart” so screen readers announce what they’ve entered.

The WebAIM 2025 study also found that pages using ARIA had over twice as many errors (57 on average) compared to pages without ARIA (27 on average). Misused ARIA causes more problems than no ARIA at all. Only add what you need, and test it with an actual screen reader.

Screen Reader Announcements

When the drawer opens, the screen reader should announce the drawer’s label. When it closes, the user should hear that they’ve returned to the main content.

Using aria-live regions or properly managing focus handles this automatically in most cases. But it’s one of those things you won’t catch without manual testing, because automated tools (which only detect roughly 30% of WCAG issues, per Accessibility.Works) can’t evaluate the screen reader experience.

Persistent and permanent drawers are less tricky. Since they don’t overlay content or trap focus, they don’t need aria-modal. Treat them as landmark regions with role="navigation" or a <nav> element and you’re mostly covered.

Drawer Components in Popular Design Systems and Libraries

You don’t need to build a drawer from scratch. Every major design system component library ships one, and most handle animation, positioning, and accessibility out of the box.

But they don’t all work the same way. The defaults, the API surface, and the level of built-in accessibility vary more than you’d expect.

Material Design and MUI

MUI’s @mui/material package pulls over 4 million weekly downloads on npm as of early 2025 (DEV Community). It includes three distinct drawer variants: temporary, persistent, and permanent.

The temporary drawer is the most common. It opens with an overlay scrim, closes on Escape or backdrop click, and handles focus trapping automatically.

MUI also offers a SwipeableDrawer for touch devices, though their own docs warn it adds a 2 kB gzipped payload and may struggle on low-end phones at 60 FPS.

Headless and Unstyled Options

Radix UI takes a different approach. It doesn’t ship a dedicated “drawer” component. Instead, you build one using its Dialog primitive and style it yourself.

This gives you total control over the look and animation while Radix handles all the tricky accessibility parts (focus trapping, portal rendering, screen reader announcements).

Headless UI from the Tailwind CSS team works similarly. No opinions about visual design, just the behavior and keyboard interactions baked in.

Platform-Native Guidelines

Material Design 3 specifies the navigation drawer for larger screens and recommends the navigation bar (bottom tabs) for compact screens. Their M3 Expressive update is actually deprecating the navigation drawer in favor of an expanded navigation rail.

Apple’s Human Interface Guidelines don’t include a standard drawer component at all. They prefer sheet presentations and sidebars, which is why you rarely see the classic left-side drawer pattern in native iOS apps.

Common Drawer UX Mistakes

Drawers seem simple to implement. They’re not simple to implement well.

These are the mistakes I’ve run into most often, and the ones that show up repeatedly in usability testing.

Hiding Primary Navigation Behind a Drawer

This is the big one. Putting your main app sections exclusively inside a drawer means users have to know the drawer exists before they can get anywhere.

The Zeebox A/B test (later rebranded as Beamly) showed that switching from a tab bar to a side drawer navigation cut user engagement nearly in half. Users simply stopped discovering features hidden behind the hamburger icon.

Spotify hit the same wall and replaced their hamburger drawer with bottom tabs around 2016. Their internal testing showed 30% more clicks on menu items with the tab bar, according to BrillMark.

Missing or Unclear Close Mechanism

Relying only on the scrim tap is not enough. Some users don’t realize they can click the darkened background to dismiss. Others are on keyboard-only setups where the scrim isn’t a valid target.

Always include a visible close button (X icon in the header) and support the Escape key. Both should be there, even if you also support scrim dismissal.

Drawers That Are Too Wide on Desktop

A drawer that covers 60% of a 1440px screen defeats the purpose of using a drawer at all. The whole point is that users can reference the main content while interacting with the panel.

Material Design caps mobile drawers at 280dp and tablet drawers at 320dp. On desktop, the same principle applies. If your drawer needs to be wider than 400px, consider whether a full page or a split-view layout would work better.

Scroll and Animation Issues

Two things that feel broken instantly:

• The background page scrolling while the drawer is open (scroll lock is missing)
• No transition animation, so the drawer just appears and disappears abruptly

Scroll locking on the <body> when a temporary drawer opens is a small detail that makes a huge difference. And a CSS animation on the drawer’s entry doesn’t need to be fancy. A simple 200-300ms slide transition is enough.

How to Build a Basic Drawer with HTML and CSS

Before pulling in a component library, it helps to understand what’s actually happening under the hood. A drawer is just a positioned panel, a backdrop, and a toggle.

HTML and CSS Setup

The markup is minimal. You need three elements:

• A container <div> for the drawer panel itself
• A <div> for the overlay/scrim behind it
• A button that triggers the open state

Position the drawer with position: fixed and push it off-screen using transform: translateX(-100%) for a left-side drawer. When the open state is active, bring it back with transform: translateX(0).

Why transform over left? Animating transform runs on the GPU compositor thread. Animating left or width triggers layout recalculation, which is slower and can cause visible jank, especially on mobile devices.

Add transition: transform 250ms ease on the drawer panel for the slide effect. That’s all the CSS needs to handle.

Adding JavaScript Interaction

The JavaScript part is a toggle. Click the trigger button, add a class like .drawer-open to the drawer container (or to the <body>). Click the close button or the overlay, remove that class.

A basic version is under 15 lines of code.

Where it gets more involved: focus trapping for accessibility. When the drawer opens, you need to move focus inside it and keep Tab cycling through only the drawer’s interactive elements. When it closes, return focus to the trigger button.

Libraries like focus-trap on npm handle this cleanly if you don’t want to write the logic yourself. But for a simple navigation drawer with a few links, manual focus management with querySelector and addEventListener works fine.

Portent research found that sites loading in 1 second convert 3x higher than those loading in 5 seconds. Every kilobyte matters on the frontend. Building a drawer with vanilla HTML, CSS, and JS keeps the footprint near zero, compared to pulling in a full component library just for one UI element.

Drawer Performance and Rendering Considerations

A drawer that looks great but tanks your page performance is a bad drawer. Collaborative research between NitroPack and Google showed that a 0.1-second improvement in load time increased conversions by 8.4% in e-commerce.

Drawers touch several performance-sensitive areas.

Lazy Loading Drawer Content

Don’t render the drawer DOM until it’s needed. In React, this means conditional rendering. In Vue, v-if instead of v-show. The difference matters when your drawer contains heavy content like product images, data tables, or embedded maps.

MUI’s temporary drawer uses the keepMounted prop on its internal Modal. Setting keepMounted: false removes the drawer’s DOM entirely when closed, which reduces initial page weight.

GPU-Accelerated Animations

Stick to transform and opacity for drawer animations. These properties don’t trigger layout or paint, they run entirely on the compositor.

Adding will-change: transform to the drawer panel tells the browser to promote it to its own compositing layer ahead of time. But use it only on the drawer itself, not on every element. Overuse wastes GPU memory.

Avoiding Layout Thrash with Push Drawers

Persistent drawers that push the main content sideways can cause layout thrashing if you animate the wrong property.

Huckabuy data shows conversion rates drop 4.42% per additional second of load time in the first five seconds. A janky drawer animation might only add 100ms of delay, but that kind of friction stacks up across a session.

Pre-rendered Drawer Content on Initial Load

If your drawer is server-side rendered and includes heavy content (like a full navigation menu with icons, badges, and user profile data), it increases the initial HTML payload even when the drawer is closed.

Huckabuy research also shows 53% of mobile visitors leave if a page takes longer than 3 seconds to load. A bloated initial DOM from pre-rendered drawer content directly contributes to that load time.

The fix is straightforward. Render a minimal placeholder on the server. Hydrate the full drawer content on the client side only after the first interaction or after the critical rendering path completes.

FAQ on Drawers in UI

What is a drawer in UI design?

A drawer is a slide-out panel that enters from the edge of the screen. It stays hidden until triggered by a user action like tapping a button or swiping. Drawers hold navigation links, filters, cart contents, or contextual details.

What is the difference between a drawer and a modal?

A modal sits centered on screen and blocks all background interaction. A drawer slides in from one side and lets users still see part of the main content. Drawers are better when users need to reference the page behind them.

When should I use a navigation drawer?

Use a navigation drawer when your app has five or more top-level sections and screen space is limited. It works well on mobile. On desktop, visible navigation or a permanent sidebar typically performs better for discoverability.

What are the main types of UI drawers?

The main types are navigation drawers (app section switching), detail or inspector drawers (properties panels), action-based drawers (shopping carts), and filter drawers. Each serves a different purpose depending on the content it holds.

How do drawers work on mobile versus desktop?

On mobile, drawers overlay most of the screen and support touch gestures like swiping. On desktop, they can be temporary overlays, persistent side panels, or permanently visible sidebars depending on the available screen width.

Are drawers accessible for screen reader users?

They can be, but only with proper implementation. Temporary drawers need role="dialog", aria-modal="true", focus trapping, and Escape key support. Without these, keyboard and screen reader users cannot interact with the drawer properly.

What is a bottom sheet drawer?

A bottom sheet is a drawer variant that slides up from the bottom of the screen instead of the side. Google Maps and Apple Maps both use this pattern. It’s thumb-friendly on mobile and works well for contextual actions or details.

Which component libraries include a drawer component?

MUI, Ant Design, Chakra UI, and Radix UI all ship drawer components for React. Headless UI from the Tailwind CSS ecosystem offers an unstyled option. Each handles accessibility defaults differently, so check the docs.

What is the difference between a temporary and persistent drawer?

A temporary drawer overlays content with a scrim and closes when you select an item or tap outside. A persistent drawer stays open until manually closed and sits at the same elevation as the page content, pushing it aside.

How do I build a drawer from scratch?

Use a fixed-position panel, push it off-screen with transform: translateX(-100%), and toggle a CSS class to bring it back. Add a semi-transparent overlay behind it. Include JavaScript for the toggle logic and focus management for accessibility.

Conclusion

Understanding what is a drawer in UI comes down to one thing: knowing when a slide-out panel is the right choice and when it isn’t. The pattern is simple. The implementation details are where teams trip up.

Get the accessibility fundamentals right. Focus trapping, ARIA roles, keyboard support. These aren’t extras.

Pick the correct drawer variant for your screen size. Temporary on mobile, persistent or permanent on desktop. Let responsive breakpoints handle the switch automatically.

Test with real users, not just in a design tool. Nielsen Norman Group’s research proved that hidden navigation cuts discoverability. Bottom tabs, visible navigation bars, and combo approaches consistently outperform drawers used as primary navigation.

Build lean. Lazy load drawer content, animate with GPU-friendly properties, and skip the heavy component library if vanilla CSS and JavaScript can do the job.