Modal vs drawer vs page
A modal blocks the whole page until the task is done. A drawer keeps the page visible behind it. A page is a destination with its own URL, not an overlay at all. Ask how much of the interface the task has earned.
The rule
Three patterns, one underlying question: how much of the interface does this task earn? A modal earns all of it. The whole page dims and freezes until the task is finished or cancelled. A drawer earns a slice. The page stays visible and often scrollable behind it, dimmed but not gone. A page earns none of the overlay treatment, because the content deserves its own URL, a back button, and a bookmark someone might return to directly. Work out which of those three the task has earned, and the right pattern follows.
Side by side
| Modal | Drawer | Page | |
|---|---|---|---|
| Blocks the page behind it | Fully | Partly, dimmed but visible | Not at all |
| Has its own URL | No | No | Yes |
| Best for | A short, self-contained decision | Content worth comparing against what's behind it | Content someone should bookmark or share |
| Cost of dismissing | Should be zero, nothing lost | Should be zero, nothing lost | Navigating away, expected, not a dismissal |
| Typical trigger | A button, for a rare or destructive action | A button, for a filter panel or a detail view | A link, or direct navigation |
| Opening another overlay from inside it | Avoid | Avoid | Fine. A page can open its own modal or drawer |
Stripe's payment confirmation is a modal, because someone has to decide, now, before anything else on the checkout can happen. Linear's issue panel, opened from a list, is a drawer: the list stays visible behind it, so opening the next issue doesn't cost your place in it. A product page on any storefront is neither. It's a page, because the content deserves a URL someone can share or return to directly.
Use a modal when
- The task must be finished or cancelled before anything else on the page can happen
- It's short and self-contained, like confirming a destructive action or editing one field
- Losing the page behind it for that moment costs nothing
Use a drawer when
- Someone benefits from comparing the drawer's content against the page behind it
- The content is a list, a form, or a set of options rather than one decision to force
- The viewport is narrow and the content needs more room than a popover gives
Use a page when
- The content deserves its own URL, a back button, or a bookmark someone might return to
- The task is substantial enough that a dedicated page won't sit unused
- Someone might want to open it straight from a shared link or a search result
Where people get it wrong
The common version routes a filter panel or a detail view into a modal, because "overlay" defaults to "modal" in most people's heads by habit. A drawer would let someone keep the list in view while they work through it; a modal takes that context away for no reason the task actually needs.
The reverse happens slower. A task that starts as one field in a modal grows: a second field, a section, a whole workflow like checkout or an onboarding sequence, until it needs its own scroll position and its own way back, and by then it should have been a page from the start. Nobody decides to make that mistake. It accumulates one field at a time.
Nesting compounds both. Opening a modal from inside a drawer, or a drawer from inside a modal, stacks two dimmed backdrops that each need their own focus trap and each need dismissing before someone gets back to where they started. Close the first layer before opening a second, or accept that the task needed a page.
A quick way to check: cover the browser's URL bar with your hand. If the content still makes sense to someone arriving fresh, with nothing but a link, it was a page. If it only makes sense next to what's still visible behind it, it's a drawer. If it needs the rest of the screen out of the way entirely, it's a modal.
Last reviewed 30 JUL 2026