Components · Notifications

Modal

A modal is the most disruptive notification. It blocks the page until the user makes a decision, so use it only when the user must confirm or choose before going on.

Every “Open modal” button opens the real dialog: try ESC, a click on the dark overlay, Tab and the × to close it. Figma: E-Com Modal.

Playground

Choose size, label and content and the preview and its code update. Press Open modal to open the real one over this page.

Breakpoint
Size
Label

The fade in and out is set in Motion.

Markup for this selection

HTML

In action

Three situations that really need a decision. The line under the list tells you how the last modal was closed, because a modal must close in all of these ways: the ×, the ESC key and a click on the overlay.

No modal opened yet.


Overview

A modal is the most disruptive notification. It blocks the page until the user makes a decision, so use it only when the user must confirm or choose before going on.

It is shown over a dimmed page and it always closes with the ×, the ESC key and a click on the overlay. Feedback belongs in a Toast, status in context in an Inline notification. Not sure it is the right component? Start at the Notifications guide.

This documentation has three pages. Examples & Guidelines (this page) shows when and how to use a modal. Specifications holds the values: tokens, sizes, measurements and requirements. Code shows how to open a modal from script and the CSS behind it.


Usage

When to use

Use a modal when the decision cannot wait. Use it to:

  • Confirm a destructive action, such as deleting an account or an address
  • Ask for a choice that the user must make before going on
  • Show crucial information the user must not miss, such as updated terms

When not to use

For a decision, not for feedback

A modal stops the user. Feedback on something that has already happened does not need that: use a Toast.

Do use a modal for a decision the user must make.
Do not use a modal for feedback. Use a Toast instead.

Name the action

The primary button says what will happen: “Delete”, not “OK”. The cancel button says how to back out.

Do name the action on the button.
Do not use a vague label such as “OK”.

Quick reference

The message…Use
needs a confirmation or a choice before the user can continueModal (this page)
confirms what happened, brieflyToast
is status information in page contextInline
concerns the whole page or systemBanner

Do

  • Ask one clear question and give one primary action.
  • Name the action on the button: “Delete”, not “OK”.
  • Close on ×, ESC and a click on the overlay, every time.
  • Move focus into the dialog and back to the opener on close.
  • Start with Small; use Large when the task needs more work area, at every breakpoint.

Don’t

  • Use a modal for feedback. Use a Toast.
  • Use it for status in page context. Use Inline.
  • Open one on page load.
  • Open a modal from a modal.
  • Use Large only because the screen is large or narrow, or the text is long.

Anatomy

Modal

  1. Label. Optional. alt-label-sm, uppercase, in text-secondary.
  2. Title. title-md, bold.
  3. Close. A Blank icon button, 20px icon. Always present.
  4. Body. body-md, text-secondary.
  5. Cancel. A Blank button, 32px high.
  6. Primary action. A Primary button that fills the rest of the row.
  7. Overlay. surface-opacity-black-20, covers the page. The dimmed area in the figure.

Variants

A modal has no status or emphasis. It varies in size (under Sizes) and in whether it carries a label.

Breakpoint

Without a label

The default: a title, a body and two buttons.

With a label

A small uppercase label above the title names the area the question belongs to, such as “Account” or “Cart”.


Sizes

The modal comes in two sizes to choose between: Small and Large. Choose by the user’s task and need for work area. The breakpoint does not change that choice: it decides how the chosen size is adapted to the screen.

Small: short decisions and simple content

Use Small when the user is to make a quick, bounded decision or take in short information. The content is easy to overview and needs no extensive scrolling. Examples:

  • Confirm or cancel an action, such as removing a product.
  • Approve a message that needs an active approval.
  • Choose between a few simple options.

Large: tasks that need a work area

Use Large when the user needs more room to read, choose or enter information. Examples:

  • Fill in a more extensive form.
  • Search or choose in a longer list.
  • Configure a product with several options.
  • Handle content with a more complex layout.

Rules for choosing a size

  • Start with Small. Use Large when the task needs more work area.
  • Do not choose Large only because the screen is large or the text is long.
  • Choose Large if Small makes the content cramped, hard to overview or hard to work with, for example when it needs a lot of scrolling or gives too little room for input.
  • Keep the same size choice across breakpoints for the same task. The responsive presentation adapts without changing what the modal is used for.
  • Do not use Large for a short confirmation only because the screen is narrow.

Rule of thumb: Small for short decisions. Large for tasks that need more work area.

Responsive behavior

The breakpoint controls how the chosen size is presented. The table sums up the three setups (the Figma breakpoint groups); exact values are under Sizes in Specifications. The figures below follow the Breakpoint toolbar.

Desktop (769px+)Tablet, sm (640–768px)Mobile, xs (below 640px)
Figma breakpointXLarge-Large-MediumSmallXSmall (Large and Small only)
Small440px wide, centered440px wide (adapts to the available width), centeredCentered card, height by content, at least 16px side margin: max width 440px; 343px on a 375px viewport
Large705px wide, centered576px wide (adapts to the available width), centeredFills the whole screen (375 × 100dvh): content on top, buttons pinned to the bottom
HeightBy content, limited by the available screen heightBy content, limited by the available screen heightSmall: by content, limited by the screen height. Large: 100dvh
Padding24px24px16px
TypeDesktop sizes (label 14, title 20, body 17)Mobile sizes (label 12, title 18, body 16)Mobile sizes
Space above the buttons32px24px24px
OverlayDims the pageDims the pageSmall: dims the page. Large: covers it completely

Desktop (XLarge, Large and Medium breakpoints)

Small is a compact dialog. Large is a wider work area. The height follows the content and is limited by the available screen height.

Tablet (Small breakpoint, 640–768px)

The same usage rules apply, but the width adapts to the available area. Both sizes keep their side margins.

Mobile (XSmall, below 640px)

  • Small: a height that fits the content and a maximum width of 440px. The dialog is centered with at least 16px side margin on each side. On narrower screens the width adapts to the available space: on a 375px viewport it is at most 343px wide, so 343px is not a fixed width for the whole breakpoint.
  • Large: a full-screen presentation for tasks that need a larger work area. Long content scrolls, and the layout has to work with the keyboard open.
Breakpoint

Small

Large

Choose Mobile in the Breakpoint toolbar to see Large as a full-screen view (a 375 × 560px screen here; the real one is 100dvh). Under Window the figure follows the width of your window.

Common layout rules

  • Small and Large do not have fixed heights. Avoid unnecessary empty space, except in the full-screen view on mobile.
  • Limit the height to the available screen area and allow scroll when the content does not fit.
  • Make sure the content and the actions can be reached in landscape orientation and when the keyboard is open.
  • A short dialog must not fill the whole screen width and at the same time be vertically centered. A centered dialog uses side margins; a full-width bottom sheet is a separate presentation pattern, not a Small modal.
  • Use a clear title and button labels that name the action, such as Cancel and Delete.

The footer is not sticky: when the content is taller than the screen, the whole panel scrolls, buttons included. On a full-screen Large with short content the buttons sit at the bottom of the screen.


Layout & Appearance

Alignment

The label and the title sit on the left with the × on the right, top-aligned. The buttons are on one row at the bottom: Cancel on the left, and the Primary button fills the rest.

Placement

Desktop and tablet: the modal is centered in the window over a dimmed overlay. Mobile (below 640px): Small stays a centered card with side margins; Large is not centered, they fill the whole screen. See the table and the layout rules under Sizes.

Width

Small 440px (on mobile too: max width 440px, never closer than 16px to the screen edges, so 343px on a 375px viewport). Large 705px on desktop, 576px on tablet, full screen on mobile.

Appearance

A white panel with the highest shadow, over a 20% black overlay. Token names and values are under Design Tokens in Specifications.


Behavior

Dismissal

A modal always closes in three ways: the ×, the ESC key and a click on the overlay. A click inside the panel does not close it.

Focus

When the modal opens, focus moves into the dialog and the page scroll is locked. Tab and Shift+Tab stay inside the dialog. On close, focus returns to the button that opened it.

On mobile (XSmall)

Small is a centered card that keeps at least 16px to the screen edges and has the height of its content; if the content grows beyond the screen, the card gets a maximum height and scrolls inside. Large fills the screen: the content scrolls, the buttons stay pinned to the bottom, and the layout has to work in landscape and when the keyboard is open. The choice between them is under Sizes.

Hover and focus

Buttons and the × take focus with a visible ring, on keyboard use only. All values are under Behavior in Specifications.

Motion

The overlay fades; the panel fades and moves 48px, up when it comes in (200ms, decelerate emphasized) and down when it leaves (150ms, accelerate): a modal closes faster than it opens. Try other values under Motion above, and see Motion in Specifications. With reduced motion there is no fade.


Accessibility

All requirements are listed under Accessibility Requirements in Specifications.

Keyboard support

Tab and Shift+Tab move between the controls and stay inside the dialog. Esc closes it. Enter or Space activates the focused button.

Screen reader support

The panel is role="dialog" with aria-modal="true" and aria-labelledby pointing at the title, so the dialog is announced with its name.



References