Inspiring Form Progress Bar Examples You’ll Want to Copy

Table of contents

Typeform draws a thin line across the top of the screen. Microsoft Forms prints “Page 1 of 3”. Gravity Forms lets you pick between a bar and labeled steps. Nearly every builder ships some version of a progress bar, and most people switch it on without ever checking whether it does anything.

The evidence is thinner than you’d hope. A 2013 meta-analysis of 32 randomized experiments on web surveys (Villar, Callegaro and Yang, Social Science Computer Review) found that a constant-speed bar did not significantly reduce drop-off. A fast-then-slow bar did reduce it, though, and a slow-then-fast bar pushed drop-off up.

What Styles of Form Progress Bar Exist?

You’ll mostly run into a linear bar, a numbered stepper, a segmented bar with step labels, a percentage counter or a circular indicator. A plain-text counter such as “Step 2 of 4” sits happily alongside any of them.

Style	What it shows	Best fit	Main weakness
Linear bar	Filled share of the total	Short to mid-length forms	No stage names
Numbered stepper	Current number among all steps	Forms with distinct stages	Crowds on narrow screens
Segmented bar with labels	Named stages, current one marked	Checkout, applications, onboarding	Needs short step names
Percentage counter	Exact share complete	Forms with even-sized pages	Misleads when pages are uneven
Circular indicator	Share complete in a ring	App screens, compact headers	Hard to fit stage names

In Guidewire’s Jutro documentation, the simple bar shows completed steps over total steps by default, and a setting flips it to a percentage.

Progress bar versus step indicator

A progress bar is just a filled line growing toward a total, and it works fine when the pages are interchangeable. A step indicator is a different animal. It marks the current stage among numbered or named ones, so people can see what’s coming next.

Jutro draws the same line in its own components. The simple bar tracks operations such as loading, uploading or submitting. Multi-step forms are what the step progress bar is for.

Naming isn’t consistent across design systems either. Visa’s lists stepper, step wizard, progress wizard and progress indicator as names for a single wizard pattern, and adds that users should always be able to edit completed steps.

Choosing a style by form length and structure

Let the form’s structure pick the style, and leave visual taste for last.

Named stages like shipping, payment and review suit labeled segments or a numbered stepper.
Pages of similar size with no real names are fine with a plain linear bar.
Uneven pages or branching paths call for stage labels, or no percentage at all.

Circular indicators fit app screens and tight headers better than long web forms.

Progress Bars Examples

Progress indicators come in several distinct styles. Each serves different use cases and design requirements.

What Should a Form Progress Bar Measure?

Steps are the safest thing to measure. Fields misstate effort when pages are uneven, and a time-remaining readout promises a number the form can’t verify for each user.

Whether to count pages or fields

Microsoft Forms and SmartSuite count pages, and Formidable Forms builds its bar from the page breaks you place in the form. A step count stays stable once those breaks are set, and it’s easy to label. The catch is that a 2-field page and a 9-field page weigh the same. A field count would be fairer to uneven pages, but it needs every field known up front.

Time is the one you can’t avoid. SoundRocket’s Scott Crawford describes survey experiments in which the same early questions implied very different remaining times depending on how fast the bar moved. Respondents read bar position as a time estimate, whether the designer intended that or not.

Handling conditional logic

Branching is where bars break, and Typeform’s Help Center documents it. When paths have different lengths, the bar can go from more full to less full while the respondent is moving forward.

The form can’t calculate completion before it knows which path the respondent will take, so Typeform advises switching the bar off when path lengths differ.

Usually it comes down to conditional logic that reroutes users after they start, and any builder that adds or skips pages mid-form runs into it.

Typeform’s advice is to switch the bar off for branches of unequal length. Shout’s survey documentation offers a setting that hides pages only some respondents see from the count. Stage labels with no total are the other way out.

If the total changes halfway through, users read it as a broken promise. Better to drop it.

Where Should the Progress Bar Go on the Form?

Put it at the top, above the first field, and pin it on long forms. Most of the documented defaults agree.

Typeform runs a horizontal line along the top, and SmartSuite puts its bar at the top of multi-page forms. Formidable Forms places it below the form title by default, with a position setting, and Shout offers Compact, Top with labels, or Bottom with labels.

Guidance splits on the bottom. Leadcapture’s multi-step form guide recommends keeping the bar there, while a Heyflow guide puts it above the question on mobile.

One quasi-experimental comparison, a 2011 Chulalongkorn University master’s thesis, reported that indicator position had no significant effect on questionnaire completion. What did matter was display rate. SurveyMonkey’s randomized test, described later in this guide, did find small differences by position.

So choose the position for visibility, and spend the testing effort on pacing.

Phones come down to space. Reform’s builder hides the step labels on small screens and keeps the bar itself visible. The fields and buttons around it get covered in these best practices for mobile forms.

Does a Form Progress Bar Increase Completion Rates?

Not reliably. The meta-analysis of 32 randomized experiments found that a steady progress bar did not significantly reduce drop-off (Villar, Callegaro and Yang, Social Science Computer Review, 2013).

What the experiments found

How fast the bar moved mattered more than whether there was one. Bars that raced ahead early reduced drop-off, and bars that crawled at the start increased it. A constant bar changed little.

Among studies that promised a small incentive, a constant bar raised the drop-off rate.

The break-off rates come from the Conrad, Couper, Tourangeau and Peytchev experiment (Interacting with Computers, 2010), as reported by SoundRocket’s Scott Crawford:

About 14% broke off with a linear-pace bar
Nearly 22% broke off with a slow-to-rapid bar
Just over 11% broke off with a rapid-to-slow bar
Just under 13% broke off with no bar at all

Even the linear bar landed above the no-bar control.

Since a bar alone does not reliably cut drop-off, pair any test of it with other fixes for lowering your form abandonment rate.

Why the effect is mixed

A bar changes how heavy the task looks. Crawford’s earlier experiments with Couper and Lamias (2001) found almost 6% lower completion with an indicator than without one (68.5% against 74.4%). With a bar on screen, respondents who had been promised a short survey (8 to 10 minutes) broke off at higher rates than those told it would take 20 minutes.

A bar that shows less work than people expected can help. One that shows more tends to backfire.

Matzat, Snijders and van der Horst (2009) found that differences between indicator types came mainly from inexperienced respondents.

The motivation theory behind form bars comes from reward research. Kivetz, Urminsky and Zheng (Journal of Marketing Research, 2006) found that people intensify effort as they near a reward, and that an illusion of progress alone speeds up purchases.

Nunes and Dreze (Journal of Consumer Research, 2006) gave car wash customers loyalty cards with free pre-stamped spaces, and the head-start cards were completed at a higher rate. That’s the endowed progress effect.

Both studies tested rewards, not forms. The survey experiments above are the closer match.

Whether to start at 0%

Leadcapture’s guide hides the bar on the first step and starts it on the second. Heyflow’s guide goes the other way and recommends a small head start on the first screen, citing the endowed progress effect.

Both are practitioner advice. The controlled evidence on head starts comes from loyalty cards, not forms, and a bar that opens above zero is a pacing choice, which the survey results say matters. Start it at a modest, honest position and test it against no bar.

When a Form Progress Bar Does Not Help

Skip the bar on short forms. In a study of 25,080 real-world web surveys from a single online panel, surveys without a progress bar had higher completion rates than surveys with one (Liu and Wronski, Social Science Computer Review, 2018).

The data is observational, so it shows an association, not proof that bars cause drop-off. It does remove the assumption that a bar can only help.

Forms too short to need one

Baymard Institute’s checkout usability research says an ideal checkout flow can shrink to as few as 12 form elements.

A form that size fits on one screen, and a bar on it measures nothing.

Whether to split a form at all is a separate decision, weighed in this comparison of multi-step forms versus single-step forms.

When placement turns against you

SurveyMonkey ran its own split test on progress bar type and position. Its two control surveys had no bar, and completion was 87% for the short survey and 89% for the long one.

Top placement with percent complete came in lower than the controls in both the short and the long survey. Bottom placement beat the controls in every variant except the bar with a page number on the long survey.

SurveyMonkey described the gaps as only a few percentage points, and it moved its own default to the bottom after the test.

That cuts against two earlier points. The 2011 Chulalongkorn thesis found no significant effect from position. And the top placement Typeform and SmartSuite document as their default did worse than the bottom in SurveyMonkey’s test, with top bars carrying a visual scale or page number giving mixed results and the top bar with percent complete falling below both no-bar controls.

The designs differ and the gaps are small, so I’d treat placement as a minor lever. If you test one combination before shipping, make it top with percent complete.

Showing the bar versus hiding it

Showing the bar gives long forms with named stages some orientation. What it costs is extra placement and pacing choices, any of which can lower completion. Hiding it leaves nothing to keep accurate as pages change, but people on a long form get no sense of how long it is.

If the bar is the only thing making a long form bearable, trim the form first. Some multi-step builds kill conversions on their own.

How to Add a Progress Bar in Popular Form Builders

Most builders tie the bar to multi-page forms, so you add the page breaks or sections first and switch the progress setting on afterward. In a WordPress form plugin with multi-page forms, a bar can show the page name and completion percentage as visitors move through.

Builder	Styles offered	Where to enable	Documented limit
Google Forms	One bar	Settings, Presentation tab	Tracks sections only
Gravity Forms	Progress Bar, Steps, None	Page Break field settings	Starts as if step one is done
WPForms	Progress Bar, Circles, Connector	First Page settings of a Page Break	Connector can misrender on mobile
Jotform	Progress Bar widget	Widgets tab in the form builder	Classic forms only
Formstack	Progress indicator	Form Extras panel	Needs more than one page

Google Forms

Google announced the progress bar in a September 2013 Drive blog post as a checkbox in Form Settings. A 2026 Formswrite guide places the toggle under Presentation and says it reports position through the sections.

The bar comes in a single style, so labeled steps or circles mean switching tools. These Google Forms alternatives are a starting point.

Gravity Forms

The documentation splits the choice in two. A Progress Bar fills as pages advance, while Steps shows labeled stages and suits pages that are clear, named sections.

By default the bar starts as if the first step is already complete, so page one never shows empty. The gform_progressbar_start_at_zero filter resets that.

WPForms

The First Page settings of a Page Break offer Progress Bar, Circles or Connector, a color picker, and a Progress Text field for the bar style. The docs warn that Connector may not display correctly on mobile and recommend Progress Bar or Circles for every device.

For a wider look at the two plugins, see this head-to-head comparison of WPForms and Gravity Forms.

Jotform

Its help center (January 21, 2026) lists the Progress Bar widget as available for Classic forms only. Card forms show progress on their own, and a Jotform support reply says a form setting hides it.

Support replies also describe the widget as tracking answered fields, not pages. That makes it a field-based bar.

Formstack

The Progress Indicator toggle sits in Form Extras and works only once the form has more than one page.

How to Make a Form Progress Bar Accessible

A bar that works with assistive technology has an accessible name and a current value it can read out. Visible text such as “Step 2 of 4” should sit alongside both.

Native progress element or a div with a role

The native progress element carries the progressbar role implicitly. MDN (revised August 28, 2026) still wants a label through a label element, aria-label or aria-labelledby, and treats text between the tags as a fallback for old browsers only.

On the native element, max sets the total (default 1) and value sets the position. No min attribute is allowed. W3C’s multi-page forms tutorial suggests it when the step count depends on user input, with wording like “Step 1 of circa 7″.

Bootstrap 5.3.8 goes with a div carrying role=”progressbar” on purpose, so bars can stack, animate and hold text labels. The wrapper needs the role, aria-valuenow, aria-valuemin, aria-valuemax and an accessible name.

For a plain bar the native element is enough. Once labels or segments need to live inside the bar, switch to the div.

There’s one catch with the native element. W3C notes that some operating systems animate it, which can collide with WCAG 2.2.2 Pause, Stop, Hide, and custom styling with browser-specific pseudo-elements stops the animation.

Step indicators and visible text

W3C’s tutorial (status updated July 27, 2019) says the first step of a form should explain how many steps follow, and every step should report progress.

Put the count in the page title, as in “Step 2 of 4: Shipping Address”, and repeat it in the main heading for visual scanners, as in “Shipping Address (Step 2 of 4)”. A step list can be an ordered list with visually hidden “Completed:” and “Current:” text and links back to finished steps.

Linked steps only work if data entered on the current step is saved first.

WCAG 2.2 checks

SC 4.1.3 Status Messages (Level AA) counts progress of a process as a status message. When it changes without moving focus, a role or property must let assistive technology announce it (W3C Understanding document, updated May 11, 2026). W3C’s sufficient techniques include a live region for a progress bar (ARIA25) and role=status (ARIA22).

Bootstrap warns that labels inside a bar depend on contrast against both the track and the fill, and recommends putting labels outside the bar.

Announce on step changes only. W3C cautions that too many live announcements make an interface chatty for screen reader users.

The failure I’d watch for is a mismatch. Width and aria-valuenow are set separately in the markup, so a script that animates the fill and skips the attribute leaves screen reader users at the old value.

The bar is one part of the form, and the rest is covered in these form accessibility best practices.

How to Build a Form Progress Bar in HTML, CSS and JavaScript

Give every page of fields its own container and a heading with the count, such as “Shipping Address (Step 2 of 4)”. Hide the inactive steps.
Add the bar itself. Use a native progress element with max set to the step count, or a div with role=”progressbar”, aria-label and the three value attributes.
Set the fill width as a percentage and animate it with a width transition. Bootstrap’s default is width .6s ease.
Write a single update function. On each step change it sets the width, sets aria-valuenow, rewrites the “Step X of Y” text and moves focus to the new step heading.
Validate before advancing, and block the Next button until the current step passes its checks.
Recompute the total when the path changes. Count the steps still reachable instead of a hard-coded number, and lower the value when the user goes back.

One update function keeps the visual bar and the ARIA values from drifting apart. For the validation rules themselves, see these form validation best practices.

Bootstrap 5.3.8 ships the markup ready-made. A wrapper holds the role and ARIA values, an inner bar takes the width, and the height is set on the wrapper only.

The 5.3.0 markup replaced an older structure, which keeps working until v6, according to the Bootstrap documentation.

Back navigation is the classic bug. A 2016 Jotform support thread describes a bar that advanced correctly but did not decrease when users went back.

Form Progress Bar FAQ

Can a single-page form have a progress bar?

Mostly no. Microsoft Forms, SmartSuite and Formstack show the bar only on forms with more than one page, and Jotform’s field-based widget is the exception.

A long single page usually reads better split into steps, and a multi-step form builder handles that split for you.

How many steps are too many for a multi-step form?

No published threshold turned up in the research behind this guide. W3C advises splitting a form along logical groups of controls, such as shipping and payment, so the count follows the content.

Google Forms caps a form at 75 sections, which is a platform limit, not advice.

Should the steps in a progress indicator be clickable?

Yes, for completed steps. W3C’s multi-page forms tutorial recommends linking back to finished steps, provided data entered on the current step is saved first.

WPForms adds a limit. Its Allow Page Navigation setting works with Circles or Connector, not the Progress Bar style.

Does a progress bar replace save and resume?

No. A bar reports position, not storage.

Visa’s design system recommends autosave, or a Save button, so users can leave a wizard without losing progress. Google Forms saves signed-in respondents’ drafts for 30 days by default.

Testing a Form Progress Bar Before You Keep It

A form progress bar belongs on a form only after a split test against the same form without one, with completion counted at each step.

The test costs traffic. Half the visitors see no orientation while it runs, and a low-volume form falls short of the sessions needed to separate a gap of a few points from noise.

Trim fields and pages first, since every change there shifts the baseline for what follows. Then split-test the bar against no bar and compare drop-off at each step. A bar tested before the form is final measures a form that will change.

This advice holds as of November 4, 2026. No randomized test on live forms, as opposed to surveys, turned up in the sources reviewed, and a published form trial would become the deciding input.

A form conversion rate calculator turns each arm’s counts into a comparable rate.