How to Add a Progress Bar to Your Website in 2026

A progress bar shows a visitor how far along they are in something, whether that is reading an article, filling out a form, or waiting for a page to load. The fastest way to add one is the native HTML <progress> element for determinate tasks, paired with a small script for anything that tracks scroll position or live status.

Below are the three common types, how to build each one, and how to keep the result accessible and fast.

Choosing the right type of progress bar

Most sites need one of three patterns, and each solves a different problem.

• Scroll or reading progress: a thin bar that fills as someone scrolls down a long article.
• Form or step progress: a bar or stepper that shows how many steps remain in a checkout or signup flow.
• Loading progress: a bar that reflects how much of a file, upload, or page resource has finished loading.

Pick based on what you are measuring. Scroll position, step count, and byte count each need a different data source, even though the visual bar can look similar.

Building a reading progress bar with HTML, CSS, and JS

A reading progress bar is a fixed element whose width scales with scroll depth. Start with a simple container:

• <div id="reading-progress"></div> styled with position: fixed, a set height, and width: 0 as the starting state.
• A scroll event listener that calculates the percentage scrolled and updates the element’s width or a CSS custom property.
• A throttle or requestAnimationFrame wrapper around the scroll handler, so the update runs at most once per frame instead of on every scroll event.

The calculation itself is short: divide the current scroll position by the total scrollable height of the document, then multiply by 100 to get a percentage. That percentage becomes the bar’s width.

Using the native progress element for forms and loading states

For anything with a known total, such as a five-step form or a file upload with a byte count, the <progress> element is the more direct tool. It takes a value and a max attribute, and the browser renders the fill automatically without any JavaScript for the visual part.

For a step form, set max to the total number of steps and update value each time someone moves forward or back. For a file upload, tie value to the bytes transferred, which most upload APIs report through a progress event. Because the browser owns the rendering, you get consistent behavior across devices with only a few lines of styling to match your brand colors.

Making progress bars accessible

A visual bar alone is not enough for screen reader users, so pair it with the correct ARIA roles when you are not using the native element.

• Add role="progressbar" to any custom (non-<progress>) bar element.
• Set aria-valuenow, aria-valuemin, and aria-valuemax, and update aria-valuenow whenever the bar changes.
• Give the bar an accessible name with aria-label or aria-labelledby, such as “Form completion” or “Reading progress”.

The native <progress> element already exposes this information to assistive technology on its own, which is one more reason to reach for it whenever the task fits.

Keeping progress bars fast

Progress bars run on scroll or input events, so a careless implementation can add noticeable jank to a page. A few habits keep it smooth: animate width or transform rather than properties that trigger layout recalculation, throttle scroll listeners with requestAnimationFrame, and avoid reading layout properties like offsetHeight inside the same loop that writes styles, since that pattern forces the browser to recalculate layout repeatedly. For most single-page use cases, a plain CSS transition on width, driven by a lightweight scroll or input listener, is enough and needs no external library.

I write runbooks as a gift to the version of my team that is tired, stressed, and reading them at midnight.

Itamar Haim

Where Sticklight fits

Sticklight is the vibe-coding platform for professional web creators, built for people who want to describe what they need and get a working result rather than assembling it element by element. A prompt like “add a reading progress bar to this article template, accessible, matching the site’s accent color” turns into working code you can review and adjust, on top of a full production-ready website, app, dashboard, or CMS rather than a single page.

That scope is what sets Sticklight apart from a single-purpose builder: it is meant to grow from a page detail like a progress indicator into whatever a full-stack creator needs next, from a form flow to a whole admin panel.

WordPress and Elementor remain part of that picture rather than something to move away from. A site built in Elementor can gain a Sticklight-built interactive piece, such as a form progress tracker or a custom dashboard, extending what the existing site can do.

Frequently asked questions

What is the easiest way to add a progress bar to a website?

For anything with a known total, such as a step form or a file upload, the native HTML progress element is the easiest option, since the browser renders the fill for you with just a value and a max attribute.

How do I build a scroll or reading progress bar?

Use a fixed-position element whose width is updated by a scroll event listener, based on the percentage of the page scrolled so far. Wrap the calculation in requestAnimationFrame so it does not run on every single scroll event.

Is the HTML progress element accessible by default?

Yes, the native progress element exposes its value to screen readers automatically. Custom bars built from divs need role, aria-valuenow, aria-valuemin, and aria-valuemax added manually to match that behavior.

Can a progress bar slow down a page?

A poorly built one can, especially if it reads layout properties and writes styles inside the same scroll loop. Animating width or transform with a throttled listener keeps the effect smooth.

Do I need a JavaScript library to add a progress bar?

Usually not. A native progress element covers step and loading indicators, and a short scroll listener with a CSS transition covers reading progress, so most sites do not need an external library for this.

Built by the Elementor team. Powered by Claude.

Let it glow.