React Progress Bar Component Examples

The shortest possible Progress. Pass a value between 0 and 100 to render the bar at that fixed percentage. The component computes pct = Math.min(100, Math.max(0, (value / max) * 100)) and writes the result into the inner <div> width via the style prop. The default max is 100, so <Progress value={65} /> renders a bar that fills 65 percent of the track. The transition class on the bar (transition-all duration-300 ease-out) means subsequent value changes animate over 300 milliseconds with an ease-out curve.

This is the right starting shape for a static dashboard widget (project completion at 72 percent), a profile completion indicator, a quota meter that shows the current usage of a known cap, and any other "here is the current value, no live updates" case. The component is a Server-Component-safe import because the registry source ships without 'use client' — meaning the bar can sit inside a Next.js app/ page that fetches the value at request time without forcing the surrounding tree onto the client. For an interactive sibling that lets the user set the value, see the Drivn Slider component.

For an upload bar that ticks in real time, hold the percentage in a React.useState and update it from the upload progress event. The example below simulates the cadence with a setInterval that increments the value by 4 every 200 milliseconds and clears when the value hits 100. In production, replace the interval with the actual upload progress source — a fetch upload progress event, an XHR onprogress callback, a tus-js-client progress handler, or whatever the storage SDK exposes. The Drivn Progress bar transitions between consecutive values through its built-in transition-all duration-300 ease-out, so the perceived motion is smooth even when the underlying source ticks discretely.

The 'use client' directive on this example file is necessary because the call site itself uses React.useState and React.useEffect — the Progress component does not force the boundary, the surrounding example does. For a cleaner separation, wrap the upload logic in a custom useUploadProgress hook that lives in a 'use client'-marked utility file and import the hook from the surrounding component. See the upload pattern shape used on Drivn vs shadcn Progress for the transform-vs-width trade-off discussion that matters for very high update frequencies.

The max prop exists for exactly this. Pass the current step as value and the total count as max, and the component handles the division — step 2 of 5 renders at 40 percent, step 4 of 5 at 80. Doing it this way rather than computing (step / total) * 100 at the call site pays off when the wizard changes shape: adding a sixth step means editing one number in one place instead of hunting down every percentage expression that hardcoded five. The same shape covers tasks-completed-out-of-total, lessons in a course, and any other discrete counter with a fixed ceiling.

Put a text label above the bar — Step 2 of 5 — reading from the same state the bar reads from, so the two cannot drift apart. The bar already announces itself through aria-valuenow and aria-valuemax, but a visible label hands sighted users the discrete count instead of a percentage they have to reverse-engineer from a filled width.

Progress is the passive half of this pattern. When the steps should be clickable — jumping back to shipping details from the payment screen — reach for the Drivn Stepper instead, and keep Progress for the cases where the user reads their position rather than navigates it.

A scroll-progress bar at the top of a long article tells readers how far they are through the content — a common pattern on blog posts, documentation pages, and long-form essays. Listen to the scroll event on window, compute the percentage as scrollY / (documentHeight - viewportHeight), and pass the clamped result to <Progress />. The Drivn component clamps to [0, 100] automatically, so the scroll math does not need to guard against the value exceeding 100 when the user over-scrolls past the document end on a touch device.

Position the bar with fixed top-0 left-0 right-0 z-50 to pin it across the top of the viewport, and reduce the track height for a thinner indicator by passing className="h-1" — the className flows through cn() and overrides the default h-2. The 300-millisecond bar transition feels slow at scroll cadence, so for a tighter scroll feel pass className="h-1 [&>div]:transition-none" (or fork the registry source to drop the bar transition entirely). The pattern pairs well with a fixed Drivn Header sitting just above it.

A password-strength meter ties the percentage to a rule set rather than an external counter. Compute the score from the password contents — length, presence of digits, presence of symbols, mixed case — and map the score onto the [0, 100] range. The example below scores out of five rules (four character classes plus length ≥ 12) and renders the bar at twenty percent per satisfied rule. Pair the bar with a short label that names the strength tier ("Weak", "Fair", "Strong") so the user gets a categorical read in addition to the percentage.

For color tiers (red below 40 percent, amber 40-70, green above 70), override the bar color through a Tailwind arbitrary-value selector: className="[&>div]:bg-destructive" for the red tier, [&>div]:bg-warning for amber, and the default bg-primary for green. The bar transitions smoothly between colors because the transition-all class on the inner <div> covers the background-color transition out of the box. For form-level validation that drives the percentage, pair the meter with the Drivn Input and react-hook-form plus zod — the same zod schema can score the password and gate the submit button.