Version 8.0.1

Progress bar

Progress bars show the progression of a system operation: downloading, uploading, processing, etc., in a visual way. They can represent either determinate or indeterminate progress.

Example of a progress bar in action, with “Loading data…” label, filling track to value of 100%.


Diagram of the anatomy of a progress bar, including label, track, value, and fill.


Example of the progress bar default variant with blue fill and gray track, label "Loading data..." at 33%.

Default variant#

Progress bars are used to visually show the progression of a system operation such as downloading, uploading, processing, etc. By default, progress bars have a blue fill that shows the progress.

Example of the progress bar 'over background' variant.

Over background variant#

When a progress bar needs to be placed on top of a colored background, use the over background variant. This progress bar uses a static white color regardless of the color theme. Make sure the background offers enough contrast for the progress bar to be legible.

Example of progress bar with everything grayed out, except for label Loading data..., positioned above the track left-aligned.


Progress bars should have a label that gives context about the operation being performed. Use an ellipsis at the end of the label text to communicate that the process is in progress. In rare cases where context is sufficient and an accessibility expert has reviewed the design, the label could be undefined. These progress bars should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”). The label is always placed above the track.

Two key examples of progress bars, showing value, min value, and max value. First example, file upload. Value 15, min value 0, max value 18. Progress bar label, Uploading files… 83% completed. Second example, filter processing. Value 0.92, min value 0, max value 1. Progress bar label, Processing filter… 92% completed.

Value, min value, max value#

The value is the progress of a system operation (e.g., downloading, uploading, processing) within the progress bar’s range, from the min value to max value.

The min and max values can also can be customized appropriately for whatever the progress bar is showing. By default, the min value starts at 0 and the max value is set to 100.

These values are not applicable when a progress bar is indeterminate.

Example of progress bar with everything grayed out, except for value label 33%, positioned above the track right-aligned.

Value label#

Progress bars can have a value label that gives detailed information about the progress (e.g. "60%" or "2 of 8"). This value label works alongside the label and should not be displayed if the label itself is not displayed. It should also not be displayed if the progress is indeterminate. Similar to the label, the value label is always placed above the track.

Example of 2 progress bars at different widths.


The width of a progress bar can be customized appropriately for its context. The default width is size-2400 (192 px on desktop and 240 px on mobile).

Examples of the four sizes of progress bars, small, medium, large, extra-large, shown ascending from smallest to largest. All examples show a determinate progress bar, label Loading data…, value 26 percent.


Progress bars come in four different sizes: small, medium, large, and extra-large. The medium size is the default and most frequently used option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page.

Example of two progress bars, comparing indeterminate with determinate.


A progress bar can be either determinate or indeterminate. By default, progress bars are determinate. Use a determinate progress bar when progress can be calculated against a specific goal (e.g., downloading a file of a known size). Use an indeterminate progress bar when progress is happening but the time or effort to completion can’t be determined (e.g., attempting to reconnect to a server).

Table of options#

From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.

PropertyValuesDefault value
default / over background
text / nothing
number (from min to max)
Not applicable when indeterminate.
min value
Not applicable when indeterminate.
max value
Not applicable when indeterminate.
value label
text / nothing
small / medium / large / extra-large
is indeterminate
yes / no


Key example showing the minimum and maximum width of a progress bar.

Minimum and maximum width#

The minimum width of a progress bar is 48 px and the maximum width of a progress bar is 768 px, for both desktop and mobile platform scale. Smaller progress bars should only be used in places where it’s not necessary to have a label.

Example of progress bar with a label text that wraps to a second line.

Text overflow#

When the label is too long for the available horizontal space, it wraps to form another line. The value is always shown in full and never wraps or truncates.

Usage guidelines#

Progress bar or progress circle?#

Both progress bars and circles can show either determinate or indeterminate progress. The given area should help determine if a progress bar or circle is best for that space. Progress bars are preferred in vertically narrow areas (tables, cards, etc.) Use a progress circle for full page loading or in very small areas. Use a progress bar in a loader dialog.

Illustration of progress bar in context of preferred use in vertically narrow design.


Use the built-in style for showing a label associated with the operation. The built-in style always has a left aligned label and a right aligned percentage value above the track. The label should be in sentence case. Add an ellipsis ("...") to the end to show that the action is in progress (e.g., "Loading data..." or "Updating settings...").

Illustration of a progress bar implemented with the preferred built-in label.

Do use the built-in label style.

Illustration of a progress bar implemented with a non-preferred custom label center-aligned.


Key example of indeterminate and determinate progress bar using a mirrored RTL layout.


For RTL (right-to-left) languages, the layout of the progress bar is mirrored for both determinate and indeterminate options. The label is right-aligned, the value is left-aligned, and the fill progresses from right to left. Keep in mind that the placement of the percent sign differs depending on the locale.


A theme is an intentional, systematic customization of Spectrum. It has unique visual attributes. For more information, view Theming.

Key example of a progress bar in the Spectrum for Adobe Express theme. Label, Loading data... at 33% complete.

Spectrum for Adobe Express#

Progress bars remain the same across themes.


Dec 15, 20228.0.1
  • Migrated to latest token system
  • Added sizes to UI kits
Apr 06, 20228.0.0
  • Updated all colors to 6.0.0
Jan 19, 20227.0.0
  • Added two size options (medium, extra-large)
Aug 23, 20216.1.0
  • Added min value and max value options
Apr 24, 20206.0.0
  • "Bar loader" has been renamed to "progress bar"
Dec 12, 20195.1.1
  • Updated RTL internationalization guideline to include the indeterminate option
Aug 22, 20195.1.0
  • Added text overflow behavior
Apr 19, 20195.0.0
  • This component is now individually versioned (individual versions of existing components start at 5.0.0)
  • Added an indeterminate variant
  • Added RTL (right-to-left) guidelines

Design checklist#


All interactive states

Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).

All color themes

Works properly across all four color themes (lightest, light, dark, darkest).

All platform scales

Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).

Accessible use of color

Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).

Accessible contrast for text

Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).

Accessible contrast for UI components

Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).

Content design

UI language and information design considerations have been incorporated into component design.

Defined options

Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)

Defined behaviors

Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.

Usage guidelines

Includes a list of dos and don'ts that highlight best practices and common mistakes.

Writing guidelines

Includes content standards or usage guidelines for how to write or format in-product content for the component.

Internationalization guidelines

Works properly across various locales and includes guidelines for bi-directionality (RTL).


Keyboard interactions

Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.

Design tokens

All design attributes (color, typography, layout, animation, etc.) are available as design tokens.


UI kit

Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.

Generated UI kit

Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.

In Spectrum for Adobe XD plugin

Component is included in the Spectrum for Adobe XD plugin.