Comparison file · surfaces
Dialog vs Modal Dialog vs Drawer vs Sheet vs Lightbox vs Carousel
Separate semantic dialog behavior from edge-based presentation.
Run the diagnosisCommon search decision
Drawer vs modal: decide by background access
When people search for drawer vs modal, “modal” usually means a Modal Dialog. The deciding requirement is whether the user must finish a focused task before using the page behind it, or needs an edge-entering surface that keeps more context visible.
Choose a Modal Dialog
Use it when the background must become unavailable and keyboard focus must stay inside a focused task until users finish or dismiss it.
Choose a Drawer
Use it when edge placement, progressive context, or touch-oriented movement is part of the task. Confirm separately whether it is modal.
Fast decision
Start with the behavior that changes the build
Dialog
Do not assume every dialog is modal. State whether background interaction is blocked.
Open field note ↗Modal Dialog
If users can safely continue working behind it, a non-modal Dialog, Popover, Drawer, or Sheet is more appropriate.
Open field note ↗Drawer
Drawer describes presentation. Specify modality, focus, and dismissal instead of relying on the name.
Open field note ↗Sheet
Sheet is an ecosystem presentation term, not a complete accessibility contract.
Open field note ↗Lightbox
A lightbox is a modal media viewer. Do not confuse it with a tooltip preview or a non-modal image popover.
Open field note ↗Carousel
A carousel presents a sequence of content items. Do not use it where every slide must be visible at once, or where autoplay would distract or disorient.
Open field note ↗Behavior matrix
Compare contracts, not silhouettes
| Decision | Dialog | Modal Dialog | Drawer | Sheet | Lightbox | Carousel |
|---|---|---|---|---|---|---|
| Modality | May be modal or non-modal; this entry represents the general pattern. | Modal; content outside is inert and visually obscured. | Can be modal or non-modal; must be declared. | Often modal in component libraries, but must be specified. | Modal — background content is inert and visually obscured. | Non-modal inline content region. |
| Placement | Layered over the primary document; not defined by edge entry. | Usually centered or full-screen, independent of an anchor. | Enters from a viewport edge, often bottom on mobile. | Attached to a chosen viewport side. | Centered overlay covering most or all of the viewport. | Inline content region, often full-width within a section. |
| Focus | Focus moves according to task needs and returns to a logical point on close. | Focus enters the dialog, remains within it, and returns to the invoker or a logical successor. | Depends on modality; modal drawers contain focus, non-modal drawers do not. | Follows the chosen modal or non-modal dialog behavior. | Focus moves into the lightbox; close and navigation controls are first in order; focus returns to the invoking thumbnail on close. | Arrow and dot controls follow normal tab order; some carousels trap focus when in fullscreen or modal view. |
| Dismissal | Explicit close, completion, cancel, and optionally Escape. | Complete, cancel, explicit close, and usually Escape unless destructive work requires confirmation. | Close action, Escape, outside interaction when allowed, or reverse gesture. | Close action, Escape, and optionally outside interaction. | Close button, Escape key, or click on the background scrim. | Not dismissed; arrows and dots navigate slides without closing the carousel. |
| Mobile | May become full-screen when the task needs more space. | Use a full-height or full-screen layout when necessary without losing modal semantics. | May support drag, snap points, and larger touch targets. | May occupy most or all of the viewport. | Swipe gestures may navigate media; close button must remain easily reachable; avoid requiring precision taps. | Swipe gestures supplement arrow buttons; autoplay pauses on interaction; dots must be tappable. |
Discriminating questions
Ask only what changes the result
- Should users be prevented from interacting with the page behind it?Yes / No
- Is entering from a screen edge part of the required interaction?Yes / No
- Is touch dragging or swipe-to-close a core mobile requirement?Yes / No
Implementation consequences
Turn the comparison into a build decision
The final choice must explain both the selected contract and the alternatives it excludes.
Name the task
Separate semantic dialog behavior from edge-based presentation. Write the user goal before choosing any component from a library.
Freeze the decisive dimensions
For this group, compare Modality, Placement, Focus, Dismissal, Mobile. Do not allow visual similarity to replace those requirements.
State the exclusion
Record why the closest rejected pattern fails. That reason helps a coding agent avoid silently substituting a familiar but incompatible component.
Verify the behavior
Open the selected pattern reference, copy its acceptance checks, and test focus, keyboard, dismissal, placement, content, and mobile behavior in the real interface.
Frequently asked questions
Dialog vs Modal Dialog vs Drawer vs Sheet vs Lightbox vs Carousel questions
Direct answers based on the reviewed behavior contract above.
What is the main difference between Dialog, Modal Dialog, Drawer, Sheet, Lightbox, Carousel?
Separate semantic dialog behavior from edge-based presentation. The decisive dimensions on this page are Modality, Placement, Focus, Dismissal, Mobile. Read each column as a behavior contract, not as a visual style recommendation.
How do I choose among Dialog, Modal Dialog, Drawer, Sheet, Lightbox, Carousel?
Begin with the required user task, then answer the discriminating questions above. Choose the pattern whose purpose and behavior match the evidence, and explicitly reject alternatives whose focus, input, modality, persistence, or structural contract would break the task.
Can two of these terms apply to the same interface?
Sometimes. This taxonomy includes semantic patterns, composite patterns, presentation forms, behavior variants, message channels, and generic behavior labels. A presentation term and a semantic contract can coexist, so specify each required property instead of forcing every term into a flat either-or choice.
How should I verify the final implementation?
Open the selected pattern reference and run its observable checks. At minimum, confirm the configured trigger, dismissal, focus, keyboard behavior, interactive content, placement, and mobile adaptation. Also verify the linked official or first-party source against the library you ship.