Version 1.0.0


Cards group information into flexible containers that allow users to browse a collection of related items and actions. They show a taste of information and reveal more details upon interaction.


Image illustrating through labels the component parts of a standard-style card, including a preview image, avatar, title, action menu, and empty content areas for metadata, indicators, and other actions. Image illustrating through labels the component parts of a standard-style card, including a preview image, avatar, title, action menu, and empty content areas for metadata, indicators, and other actions.
Image illustrating through labels the component parts of a quiet-style card, including a preview image placed on a frame, title, detail text, action menu, and metadata.Image illustrating through labels the component parts of a quiet-style card, including a preview image placed on a frame, title, detail text, action menu, and metadata.


[object Object]

Card container#

Standard cards use a background container to organize information. Quiet cards do not have a container; the components inside float on the background.

[object Object]


Most cards have some type of preview. The preview should appear at the top of the card, but in some cases can be placed in the center or bottom.

[object Object]

Avatars and third party logos are always circular. Adobe product logos should always honor the shape of their logo.

[object Object]

Action menu#

Any type of card can have a hidden actions menu, which is placed on the right side of the header and to the right of the heading.

[object Object]

Quick actions#

Card-level actions can either be shown in an action menu or as quick actions. Because quick actions have limited space and only work with desktop experiences, it's recommended to use either an exposed action menu or bulk actions.

[object Object]


Cards use the Heading text style for titles. The size can be customized depending on the use case, but by default, use the extra-small heading for medium and large cards and the extra-extra-small heading for small cards.

[object Object]


Detail text uses the Detail text style. This can appear to the right of the title or below it. Detail text is typically used to show a file type.

[object Object]

Only standard cards have a footer. The footer has a content area that can hold buttons on the right side and indicators (badges, icons, status lights, etc.) on the left. The footer is always divided from the card body using a small divider.

[object Object]


Badges can appear in a few different places on a standard style card. If the card has a preview, it should appear anchored to the lower right side, floating on top of the preview. If there is no preview, a badge should go in the footer on the left side. If neither of those options may work for your use case, place the badge anywhere on the card and ensure that the placement is consistent across all cards in your system.

[object Object]

Content area#

A content area can hold many different components. These areas are built into the body section and the footer of a card. Text or metadata is placed in the body section, and buttons and/or indicators in the footer.


Key example of two cards, one in standard style and one in quiet style.

Standard or quiet#

Cards can either be standard or quiet style. Use standard style for a footer with buttons and more information. Quiet style is reserved for very simple cards with little metadata.

Key example of two cards, one in vertical orientation and one in horizontal orientation.

Vertical or horizontal #

Standard cards can be laid out vertically (components are organized in a column) or horizontally (components are organized in a row).

Horizontal cards always have a square preview, and the image is cropped to fit inside the square. These can only be laid out in a tile grid where every card is the same size.

Key example of two cards, on in large size and one in small size.


Medium is the default size for a card. Use large cards on webpages where it's necessary to present a lot of content at once.

Small cards are best for small containers such as dialogs, panels, popovers, or trays. These should only have a preview, title, description, badges, and/or action menu. More details should be preserved for a one-up or detail view.

Key example of a card, showing the correct styling for selection.


Most cards are selectable. You can either turn on a "selection mode" in which checkboxes will appear in the top left corner of every card, or the checkbox can appear individually upon hover.

Key example of a card, showing the correct style for dragging.


In some cases, cards can be draggable. On desktop, the move option should be shown in quick actions and would appear on the furthest right. The checkbox and other quick actions would disappear while dragging.

On mobile, a long press would enable a drag mode that allows for cards to be rearranged.

Key example showing four different cards with varying levels of detail and different components.


The layout of a card will depend on what information needs to be shown. Each item shown in the Anatomy section is optional, but should respect the default placement if used.


Key example of two cards, first card set at minimum height, second card set at maximum height.

Preview aspect ratio#

Card preview areas can have any aspect ratio between 4:1 (shortest) and 3:4 (tallest).

The recommended default preview size is 2:1.

Key example of cards showing truncated titles for tile grid cards, and wrapping titles for masonry grid cards.

Text overflow#

If the height of the card is set (e.g., arranged in a tile grid), title text will truncate if too long. Try to write a short title to avoid truncation.

If the height of the card is variable (e.g., arranged in a vertical masonry grid), title text will wrap to fit the entire title.

Key example of four cards that are clickable.

Clickable cards#

Cards, by definition, should have some form of interaction such as viewing, editing, purchasing, etc. Some actions are exposed in buttons, and others simply occur by clicking the card.

If a card only has an ability to be opened or viewed in more detail, do not include a button. Clicking anywhere on the card should perform that action.

If a card has other interactive elements such as a hidden actions menu or an avatar, but no buttons, the whole card (outside of those elements) should be clickable.

Key example of four cards that are not clickable.

Buttons in cards#

If there’s only one action (that’s not opening or viewing the card), use a button to communicate that action. If there are two or more available actions, and one of those actions is to open or view the card, use a button to communicate “View” or “Open,” instead of relying on clicking on the card.

If a standard card has a footer with a button, only the button is clickable. If a card has a preview, clicking the preview will open that card. When a preview is purely decorative, it is not clickable.

Diagram showing the four phases of ghost loading.

Ghost loading#

When a group of cards are loading, they follow the ghost loading convention. There are 5 phases for ghost loading:

  • Card group (including metadata) ghost loads.
  • If metadata for all cards is loaded before all preview images are loaded, the metadata is displayed for all cards as soon as the last piece of metadata loads. Previews continue to ghost load.
  • If all preview images load within the x period (a period of time, usually measured in seconds, that you need to specify depending on the use case), they are shown as soon as the last preview loads.
  • If all previews have not finished loading at the end of the x period, the loaded previews are shown, and the pending previews receive individual progress circle. The group is no longer in a ghost loading state.
  • If the preview load times out, an error is shown along with a mechanism to retry loading.


Key example of cards shown in three different groupings. First card group vertical masonry grid, second card group horizontal masonry grid, third group tile grid.

Layout grid#

There are three types of layout grids to choose from to present cards:

A vertical masonry grid can vary in height, but is consistent in width.

A horizontal masonry grid can vary in width. Rows of cards may vary in height, but the cards within a row are consistent in height. Only quiet style cards are laid out in horizontal masonry grids.

A tile grid is the default layout. They are same height and width as the rest of the cards in the group. Horizontally-oriented cards are always arranged in a tile grid.

Key example showing card gutters compared to the page gutter width.

Card gutters#

Individual cards are not aligned to individual columns in the responsive column grid. Instead, groups of cards are aligned to the column grid in a layout region (a "card grid"). The gutters between the cards should be 3/4 the page gutter width. For example, if a page’s column grid gutters are 32 px, the space between cards should be 24 px.

Key example showing a group of cards laid out in a fluid card grid.

Card width#

Cards are laid out in either a fluid card grid or have fixed widths. Most cards can be organized within a grid where the width of each card is fluid depending on the nature of the grid. In rare cases where cards can’t be laid out in a card grid, they’ll have a fixed width that is defined manually.

Key example of a card showing the standard height for the preview of a card.

Card height#

Card height depends on the grid type and the content of the cards. Cards that are set in a tile grid should all be the same height.

Usage guidelines#

Keep cards simple#

Cards are meant to just show a taste of the available information. Don’t overload cards with more information than necessary.

Key example showing a simple card.
Key example showing a card that is overly complicated.

Don't add buttons to quiet cards#

Only standard cards can have a footer, and buttons can only appear inside a footer. Use a hidden actions menu or quick actions for quiet cards that need to support actions.

Key example showing incorrect combining of a quiet-style card and a button.

Don't align individual cards to the column grid#

Individual cards are not aligned to individual columns in the responsive column grid. Instead, groups of cards are aligned to the column grid in a layout region.

Key example showing correct card group alignment.
Key example showing incorrect card group alignment.

Avoid using both an action menu and quick actions#

If possible, use either an action menu or quick actions, but not both at once. Keep in mind that quick actions may not be available in touch-first experiences; create cards responsively so that actions can be available in an action menu on mobile.

Key example showing both quick actions and a hidden actions menu, which should be avoided.

Keyboard interactions#

Specific keyboard interactions will depend on the type of card you are using and what content it contains. Refer to specific card type patterns for more details.

TabMove forward to the next card
Arrow keysMove focus within the card to focusable items within the card. If a button is included on the cards, the button should receive focus first. If there are multiple buttons, the primary or CTA button should receive focus first.
Shift + TabMove focus backward to the previous card
Return or EnterIf the card itself is clickable, return or enter will open the card. If the card is not clickable but has buttons, and the buttons or another item within the card is focused, that action is performed.
SpaceIf the card is selectable, the space bar will toggle selection.
Ctrl/Command + Arrow keysNon-contiguous selection of cards.


Sep 16, 20191.0.0
  • This pattern has been added to the website