Components chevron_right Dialogs


Dialogs inform users about critical information, require users to make decisions, or encapsulate multiple tasks within a discrete process. Use dialogs sparingly because they are interruptive in nature. Their sudden appearance forces users to stop their current task and refocus on the dialog content. Not every choice, setting, or detail warrants interruption and prominence.

Alternatives to dialogs include menus or inline expansion within the current content area. Both approaches present non-interruptive options while maintaining the current context.

Content Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Dialog content can vary widely, but typically consists of text and/or UI control elements focused on a specific task or process. Examples include confirming item deletion or choosing a setting.

To disclose additional content, use inline expansion within the content area of dialogs, such as advanced options.

Avoid dialogs that:

  • Open additional dialogs from within a dialog.
  • Contain scrolling content, particularly alerts. Instead, consider alternate containers or layouts that are optimized for reading or interacting with significant amounts of content.

Exceptions include:

  • Full-screen dialogs may open additional dialogs, such as pickers, because their design accommodates additional layers of material without significantly increasing the app’s perceived z-depth or visual noise.

Use and limitations: Dialogs are a sub-type of modal windows, and the examples covered here are for standard material system dialogs.

Other modal window constructions aren’t covered here because they have too much variation. For example, they can include elements such as branded buttons for purchasing flows, non-standard UI form elements, illustrations, or unique layouts.

Example of dialog content

Example of a full-screen dialog.

Behavior Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Dismissing dialogs

Dialogs are separate from the underlying parent material and do not scroll with the parent material.

Some dialog content requires scrolling, such as lists of ringtones. If the content is a scrollable list of options, the dialog title remains pinned to the top. This behavior means that a currently selected item in a scrollable list can be visible simultaneously with the title, regardless of the item’s position in the list. Otherwise, the title scrolls off with the content. Actions always remain in place when content scrolls.

Dialogs should never be obscured by other elements and should never appear only partially on screen. Dialogs always retain focus until they have been affirmed or dismissed or a required action has been taken, such as choosing a setting.

Dialogs can be dismissed by touching/clicking outside of the dialog or by using the system back button (Android). Dialog behavior can be overridden so that users must explicitly choose one of the actions.

Make dialog title fixed when viewing a scrollable list of options ensures that both the title and the selected item are simultaneously visible.

Alerts Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Alerts inform the user about a situation or action that requires their confirmation or acknowledgement before proceeding. They differ slightly in appearance based upon the severity and impact of the message conveyed.

Alerts are interruptive, urgent, and prevent users from proceeding until they make a decision.

Disambiguation from Snackbars: In contrast to Alerts, Snackbars present optional but important information or actions and usually appear after an action. For example, use an alert to confirm discarding a draft. Use a snackbar to present an undo action, because the action is optional and the user can continue with their primary task without taking action.

Alerts without title bars

Most alerts don't need titles. Usually the decision doesn't have a severe impact and can be summed up succinctly in a sentence or two. The content area should either ask a question (such as "Delete this conversation?") or make a clear statement whose relationship to the action buttons is obvious.


The affirmative action text “Discard” clearly indicates the outcome of the decision.


The dismissive action text “No” answers the question, but does not suggest what will happen afterwards. A better action pair would be an explicit “Cancel” and “Delete.”

Alerts with title bars

Use alerts with title bars sparingly. They are appropriate only for high-risk situations, such as potential loss of data or connectivity, or extra charges.

If a title is required:

  • Use a clear question or statement with an explanation in the content area. For example, "Erase USB storage?"
  • Avoid apologies and ambiguous statements or questions. For example, don’t use “Warning!” or “Are you sure?”

A user should be able to skip the content completely and still have a clear idea of what choices are available based on the title and the text of the action buttons.


This dialog poses a specific question, concisely elaborates on its impact, and provides clear actions.


This dialog poses an ambiguous question and its scope of impact is unclear.

Simple menus Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Simple menus are used in list views on tablet and mobile devices to display the options for a specific list item. Simple menus immediately commit choices upon selection. See Components > Menus > Simple Menus for more details.

Disambiguation: In contrast to simple menus, simple dialogs can present additional detail related to the options available for a list item or provide navigational or orthogonal actions related to the primary task. Although they can display the same content, simple menus are preferred over simple dialogs because simple menus are less disruptive to the user’s current context.

Example of a simple menu

Simple dialogs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Simple dialogs can present additional details about a list item or provide actions related to the primary task. For example, simple dialogs can display avatars, icons, or clarifying subtext, or they can enable users to perform an orthogonal action such as adding an account that’s not currently listed as an option.

Touch mechanics:

  • Choosing an option immediately commits the option and closes the menu.
  • Touching outside of the dialog, or pressing Back, cancels the action and closes the dialog.

Simple dialogs are more interruptive than simple menus and should be used sparingly.

Example of a simple dialog

The width of a dialog on mobile is defined as a multiple of a unit.

Each unit is 56dp wide
Minimum width on mobile = 56dp * 5 = 280dp

Simple dialogs do not have explicit buttons that accept or cancel the operation.


  • A simple dialog appears centered vertically and horizontally in the screen.
  • The distance between the edges of the screen and the edges of the dialog is minimum 40dp on the left and right, and minimum 24dp on the top and bottom.
  • The distance between the edge of the dialog and content is 24dp.

This simple dialog has an explicit “Cancel” button.


This simple dialog has an explicit “Cancel” button.

Row heights can vary in simple dialogs.

If any text in a simple menu wraps to another line, use a simple dialog instead.


This simple dialog has varying row heights.

Confirmation dialogs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Confirmation dialogs require users to explicitly confirm their choice before the option is committed. For example, users can listen to multiple ringtones but make a final selection only upon touching “OK.”

Touching “Cancel” in a confirmation dialog, or pressing Back, cancels the action, discards any changes, and closes the dialog.

The ringtone choice in the following confirmation dialog will not be set until the user touches “OK”.

Example of a confirmation dialog with controls positioned on the left side of text.

Confirmation dialogs can use layouts other than lists, for example a date picker, but they are still focused on specifying a single value (picking the date, but not picking the time and date).

The date choice is set by the user touching a date and the “OK” button.  

The user selects the hour by moving the clock hand and touching “OK.”

Confirmation dialogs provide both an explicit confirmation button and explicit cancel button. The explicit cancel button clarifies that leaving the confirmation dialog will discard changes, for example, by touching cancel or pressing Back.

Confirmation dialogs should avoid launching additional simple dialogs or simple menus. The additional layers of material can increase the app’s perceived z-depth, and add unnecessary visual complexity.

If additional simple dialogs or simple menus are needed to complete the task or process, consider using a full-screen dialog instead of a confirmation dialog.


Provide explicit confirmation and cancel buttons.


A single dialog button makes the system Back action ambiguous: does Back cancel or confirm?

Full-screen dialogs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Mobile only: Due to limited real estate on mobile devices, dialog content appearing in other form factors (tablet, desktop, etc.) may be more appropriate on mobile using a full-screen dialog.


Full-screen dialogs group complex tasks that require explicit action, such as save or create, before changes are committed or discarded, as in a calendar entry.

Full-screen dialogs enable complex layouts, minimize the appearance of stacked sheets of material (dialogs above dialogs) and increase the app’s perceived z-depth. They enable individual tasks to launch simple menus or simple dialogs as part of the complex operation.

Consider using a full-screen dialog when the content or process meets any of the following criteria:

  • The dialog includes components like pickers or form fields requiring an input method editor (IME), such as a keyboard.
  • When changes are not saved in real time
  • When there is no draft capability in the app
  • When performing batch operations or queuing changes prior to submitting them

No modifications and selections made in the full-screen dialog are saved until “Save” is touched. Touching the “X” will discard all changes and exit the dialog.

The full-screen dialog supports a simple dialog used to pick dates.

Date picker opened from full-screen dialog


In full-screen dialogs, the confirmation and dismissive actions are at the top of the screen.


The confirmation action is at the top right of the screen and uses descriptive and accurate verbs, such as “save,” “send,” “add,” “share,” “update,” or “create.”

Don’t use vague actions such as “done,” “ok” or “close” for the confirmation action. They are too similar in meaning to the X and non-specific in their result.

The confirmation action is disabled until all mandatory criteria in the dialog are met.


The discard action, an “X” at the top left of the screen, closes the full-screen dialog and discards any changes. The Back button is equivalent to the discard action.

If the user has made any changes, they are prompted to confirm the discard action. If no changes have been made, touching the “X” or “Back” immediately closes the dialog and no discard confirmation is required.


Don’t use vague terms like “Close” for confirmation actions.


Prompt users to confirm the discard action if they have made any changes.


The “X” used in a full-screen dialog differs from an up arrow, which indicates the view’s state is constantly being saved or when apps enable draft or autosaving. For example, an up arrow is used in Settings because all changes are committed immediately. In these cases, the Back button navigation and action match the up arrow functionality, and there are no explicit confirmation or cancel actions.

The up arrow in this Settings example indicates that any changes will be immediately saved upon selection.

Touching the “X” in this Settings example will discard all changes. Changes will be saved only upon touching Save.


Full-screen dialog titles don’t use dynamic type.

Titles should be succinct.

Full-screen dialog titles can wrap to a second line if necessary, and then should be truncated.

If the full-screen dialog uses titles of variable length or anticipates long titles (for example, because certain words are longer in different languages), place title text in the content area of the dialog instead of the app bar.


Avoid using titles of variable length in the app bar.


Place long titles in the content area of the full-screen dialog.

Specs Expand and collapse content An arrow that points down when collapsed and points up when expanded.

Dialogs contain an optional title, content, and actions.

The optional title briefly describes the type of choice being made. Titles should always be displayed in their entirety and should be used only when necessary. Titles can be used to clarify the decision being made. For example, a title may indicate what part of a process the dialog relates to or identify what will be affected by the decision, such as a setting.

Dialog content can vary widely, but typically consists of text and/or UI control elements and is focused on a specific task or process, such as confirming item deletion or choosing a setting.

When needed, actions acknowledge, affirm, or dismiss the particular choice or process presented by the dialog content.

This dialog contains a title, content and actions.

A note on accessibility

To ensure usability for people with disabilities, make sure that your buttons have a minimum height of 36dp, but that the touchable target has a minimum height of 48dp.

The default color of all dialog action text is the system color. The system color can be overridden to use the application’s theme accent color. Make sure that the combination of accent color and action text doesn’t impart unintended meaning. For example, red text implying warning or danger for a non-destructive confirmation action.

Always make sure the action text color uses a sufficient contrast ratio to meet accessibility guidelines. Change the default text color as needed to create a sufficient contrast ratio.

Buttons have a minimum height of 36dp, but the touchable target has a minimum height of 48dp.


This dialog’s text uses an insufficient contrast ratio. Additionally, the red action text implies a warning or danger when neither action is destructive.


Dialogs present a focused and limited set of actions, which are generally affirmative or dismissive.

Affirmative actions are placed on the right side and continue the process. Affirmative actions may be destructive, like “Delete” or “Remove”.

Dismissive actions are placed directly to the left of affirmative actions and return the user to the originating screen or step in the process.

Dismissive and affirmative action text can be “Cancel”/”OK” or can be more specific active verbs or verb phrases that indicate the outcome of the decision.


Dismissive actions are always placed directly to the left of affirmative actions.

Dialog actions should make decisions as easy as possible by presenting a clear, unambiguous choice that directly relates to the dialog’s title and content.

  • Clearly state a potential result in the dialog title.
  • The dialog content should directly relate to the title or choices.
  • Present clear choices.

Avoid presenting users with ambiguous or unclear choices. In this example, “Cancel” doesn't make sense in relation to the title because there's no clear action being proposed.

For languages without capitalization (for example, Chinese, Japanese, or Korean), the consistent placement and spacing of actions in the bottom-right corner of the dialog, along with text color, help distinguish dialog actions from regular dialog text.

In particular, because a dismissive action is never disabled, and because the positioning of dialog actions places the dismissive action before the affirmative action in reading order, a disabled affirmative action is prevented from appearing like regular dialog text.

The consistent placement of actions and text color helps distinguish actions from regular text even when the affirmative action is disabled.

Affirmative actions are more likely to be disabled until a choice is made. Dismissive actions are never disabled.

In situations where users are required to acknowledge the dialog’s content prior to proceeding, an alert may contain only one action. However, this type of alert should be used sparingly as it is interruptive and does not provide users with a decision to make or choose an action. Consider other methods of communicating the information to users, such as in-line with a view’s content.

Dialogs generally should not include more than two actions. A third action such as “Learn more” that navigates away from the dialog or app leaves the current task and decision in an indeterminate state.

Avoid using a “Learn more” action in a dialog to access help documentation. If a little more detail or explanation is needed for the dialog contents, use in-line expansion within the dialog. If more extensive information or explanation is needed for the dialog content, provide that information prior to entering the dialog.


The learn more action navigates away from this dialog, leaving it in an indeterminate state.

Content guidelines

Padding around content area: 24dp
Padding between title and body text: 20dp
Padding around buttons: 8dp
Button height: 36dp
Action area height: 52dp
Dialog elevation: 24dp

Content padding

Within the content area, the 24dp of padding below the content helps separate it from the actions.

Content padding for a dialog in a scrolled state

Button width and padding

Button height: 36dp
Minimum button width: 64dp
Internal button padding: 8dp
Padding between buttons: 8dp

Detail of button widths and padding

Button area height: 52dp
Left button padding: 24dp
Right button padding: 8dp
Padding between buttons: 8dp

Detail of button area

In a scrolled state, a stroke delineates the dialog’s content area from actions.

Side-by-side buttons

Side-by-side buttons are recommended when the text of each label does not exceed the maximum button width, such as the commonly used OK/Cancel buttons.

Use the following formula to calculate maximum button width for a given dialog:

The maximum width for buttons in a dialog =

(Dialog width - 8dp - 8dp - 8dp)/2

For example:

The maximum width for buttons in a 280dp wide dialog =

(280dp - 8dp - 8dp - 8dp)/2 = 128dp

Button height: 36dp
Padding between text and action area: 24dp
Padding around buttons is: 8dp

Stacked full-width buttons

When text labels exceed the maximum button width, use stacked buttons to accommodate the text. Affirmative actions are stacked above dismissive actions.

Touchable target height for each button: 48dp
Padding between text and touch target: 24dp
Padding below touch target to dialog edge: 8dp
Padding between button text right edge and dialog edge: 16dp

Simple dialog keylines

Vertical keyline at 24dp from the left and right edges. Content associated with an icon or avatar aligns 80dp from the left edge.

Keylines for a simple dialog

Full-screen dialog titles

Full-screen dialog titles can wrap to a second line if necessary, and then should be truncated. Titles should be succinct, but in some situations, such as when words are longer in different languages, titles may need to wrap.

App bar height with a single line of text: 56dp
App bar height with two lines of text: 80dp
Title text keyline: 72dp
Title text: 20sp
Title text top and bottom padding: 20dp
Dismissive action padding from left edge: 16dp
Affirmative action text: 14sp
Affirmative action text padding on the left and right: 16dp

Detail of a full-screen dialog app bar

Full-screen dialog with an app bar containing a single line of text.

Note that this image is for illustration purposes only. Long titles should be placed in the content area of the full-screen dialog.