Multi-step Forms

Break one long form into steps a visitor moves through, with an optional progress bar, step counter, or dots — all from the style panel, with no code.

What it is

A long form asking for twelve things at once is a form people abandon. A multi-step form shows one group of fields at a time, with Next and Back buttons between them — the visitor still submits once, at the end.

There's no separate form type to choose and nothing to convert. You mark elements you've already built inside an ordinary form, and the platform wires up the show/hide, the validation, and the progress display when your site is built. A form with no steps marked is left exactly as it was.

Marking the steps

Group each step's fields into their own container inside the form — one container per step, normally as direct children of the form. Then select a container in the canvas, and in the style panel on the right tick Form step → This is a step of a multi-step form.

Steps run in the order they appear in the Layers tree, top to bottom. There's no step number to set — reorder the containers and the order follows.

The submit button belongs in the last step

Your form's real submit button should live inside the final step's container. Because every other step is hidden until the visitor reaches it, that's what stops anyone submitting from step one.

Can't find the controls?

Every multi-step control appears in the style panel only when the element you've selected sits inside a <form>. Outside a form these settings do nothing, so the panel keeps them hidden — if you don't see them, check what you have selected in the Layers tree.

Next and Back buttons

Add a button inside a step, select it, and pick from Form step navigation: Next step or Back to previous step. Zitegen sets the button's type for you so it never submits the form by accident.

Next checks the current step before it advances. If a field in that step is required and empty, or fails its own validation, the browser shows its usual message and the visitor stays put. Back never validates — going back is always allowed.

Required fields in later steps are handled for you

A required field the visitor hasn't reached yet would normally block submission with an error message the browser can't even show, because the field is hidden. Zitegen suspends required on every step that isn't currently visible and restores it the moment that step is shown, so this never happens.

A progress bar

Add a container beside your steps — a sibling of them, not inside one — and tick Form progress → Multi-step progress bar container. On every navigation Zitegen sets a --zg-progress CSS variable on it: the current step divided by the total, reaching 1 on the last step.

Note that it counts the step the visitor is on, not the ones behind them — a three-step form starts at 0.33, not empty. Same for Percent complete below, which reads 33 on step one.

Put one child element inside as the fill, and give it a width driven by that variable:

w-[calc(var(--zg-progress)*100%)]

Everything else — height, colour, rounding, a transition on the width — is ordinary styling on those two elements.

Step numbers and percentages

For a "Step 2 of 4" line, write the sentence as ordinary text and use a separate <span> for each live number. Select a span and pick from Form progress text:

  • Current step number — the step the visitor is on, counting from 1.
  • Total step count — how many steps the form has.
  • Percent complete — a whole number like 50. Add your own % sign as text next to it.

Type real fallback text into each span (1, 4) rather than leaving it empty — that's what shows for the instant before the page's scripts run.

Step dots

For the row-of-dots style indicator, add a container beside the steps and tick Form progress dots → Discrete step-dots container. Inside it, add exactly one element and tick Form progress dot → This is the step-dot template.

That single dot is a template, not a dot. Zitegen copies it once per step when the page loads, so a four-step form gets four identical dots from the one you styled — don't add them by hand.

Each dot carries a data-zg-dot-state of done, current, or upcoming, updated as the visitor moves. Style the states with Tailwind's attribute variants on the template dot:

bg-muted
data-[zg-dot-state=done]:bg-primary/40
data-[zg-dot-state=current]:bg-primary

Each dot also gets a 0-based data-zg-dot-index if you need to target a specific position.

Nothing else goes in the dots container

The dots container's contents are replaced with the generated dots when the page loads. Any label or spacer you put in there alongside the template will disappear — style the container itself, or wrap it in a parent.

Where progress elements go

The progress bar, the counter spans, and the dots container must all sit outside every step — as siblings of your step containers, directly inside the form. A progress indicator placed inside a step disappears along with that step the moment the visitor moves on.

All three are optional and independent. Use a bar, a counter, dots, any combination, or none.

What happens without JavaScript

If scripts are blocked or fail to load, the form doesn't break — it falls back to what it actually is underneath: one long single-page form with every step visible at once, still completely fillable and submittable. Your progress spans keep whatever fallback text you typed.

Multiple forms on the same page each run their own steps independently and never interfere with each other.

Where submissions go

Exactly where every other form's do — the Leads tab of your site's workspace, with all fields from all steps in a single submission. Steps are purely how the form is presented; nothing about capture, notifications, file uploads, or spam protection changes. See Forms & Leads for the rest.