Multi-Page Forms: Setup and TroubleshootingPRO
Long forms convert better when they’re split into short focused steps, so visitors don’t bounce off a wall of fields. This page walks through splitting a FormForge Pro form into multiple pages using the Page Break field, understanding the auto-generated progress bar and step navigation, how per-page validation works, the one directional gotcha with conditional logic across pages, and the four issues that most commonly break multi-page forms.
Open the form in the builder, drag the Page Break field from the Layout section of the palette to wherever you want the split, save the form. Every field before the Page Break lives on page 1 and every field after lives on page 2. The form auto-renders with a progress bar, Next / Previous buttons, and a Submit button that only surfaces on the last page.
How multi-page forms work
Any form that contains at least one Page Break field automatically renders as multi-page. There’s no separate toggle, no per-form setting to enable, no extra configuration. The Page Break itself is invisible to visitors, so it functions purely as a marker that tells FormForge where to split fields onto separate pages.
Every field before a Page Break lives on the previous page, and every field after it lives on the next page. Two Page Breaks produce three pages, three Page Breaks produce four, and so on.
All fields on all pages exist in the same underlying HTML form at all times. FormForge just shows the current page and hides the others via CSS, so the visitor experiences discrete steps, but the form itself is a single POST when they finally click Submit.
Add pages to a form
Open the form in the builder
Go to FormForge > All Forms and click the form name to open the drag-and-drop builder.
Arrange your fields in the order visitors should see them
Multi-page forms benefit from thoughtful ordering: put the easy, low-friction fields first (name, email) and the harder ones last (file upload, detailed message). Drag fields into the sequence you want before adding page breaks so you’re not moving them around later.
Drag the Page Break field to the split point
Find Page Break in the Layout section of the field palette (left sidebar of the builder). Drag it into the canvas at the exact spot you want the form to split. Everything above the Page Break becomes page 1; everything below moves to page 2.
Add more Page Breaks for more pages
Each additional Page Break creates one more page. Two Page Breaks give you three pages, three give you four. There’s no hard cap, but forms with more than four or five pages usually see completion rates drop, so keep the count tight.
Save the form
Click Save Form at the top right of the builder. Multi-page rendering activates automatically.
Test on a Private page
Embed the form on a page, set the page’s Visibility to Private, and walk through the form as a visitor would. Confirm: the progress bar shows the right step count, Next advances only when required fields are filled, Previous returns you to the earlier page with your typed values still intact, and the Submit button only appears on the last page.
What visitors see on the form
A multi-page form renders three UI elements the visitor uses to move through it: a progress bar at the top, per-page Next / Previous navigation buttons, and the Submit button on the final page.
Progress bar
Automatically rendered above the form when Page Breaks are present. It shows one numbered step per page (Step 1, Step 2, Step 3, and so on), with the current step highlighted and completed steps marked. A progress fill bar underneath animates from left to right as the visitor advances.
The visitor can click any completed step to jump straight back to that page. Clicking a future step attempts a forward jump, and the current page validates before FormForge advances. Backward clicks are always allowed without validation.
Next and Previous buttons
Each page except the first shows a ← Previous button on the left. Each page except the last shows a Next → button on the right. On the last page, the Next button is replaced by the Submit button, so the visitor sees Previous and Submit together. Clicking Next validates the current page’s required and email fields; if any fail, the visitor stays on the current page with the failing fields highlighted.
Scroll behavior
When the visitor advances or moves back, FormForge scrolls the viewport to the top of the form, so the visitor doesn’t have to hunt for the start of the new page. This is especially helpful on mobile where the previous page’s fields can stretch several screen-heights.
The step labels above the progress bar render as Step 1, Step 2, Step 3, and so on. Custom per-page labels (like “Contact”, “Details”, “Review”) aren’t a current setting. If you want to communicate what each page collects, use a Section field at the top of each page to render an inline heading the visitor will actually see.
How validation flows across pages
Validation happens in two places on a multi-page form, and the two work together to catch problems as early as possible without letting anything slip through at the end.
Client-side, on every Next click
When the visitor clicks Next, FormForge validates only the current page. It checks required fields (any empty required field on the current page blocks advancement) and email fields (any malformed email address blocks advancement). If validation fails, the visitor stays on the current page, the failing fields are highlighted with an inline error message, and the Next click does nothing else. This gives immediate feedback with no server round-trip.
Server-side, on the final Submit
When the visitor clicks Submit on the last page, the entire form (every field on every page) is POSTed to the server, where FormForge re-validates the complete submission. Server-side validation runs every field’s configured rules regardless of visibility state. If any field fails, the response returns the error and the visitor sees it inline on the last page. This catches anything the client-side missed, plus any custom PHP-side validation rules that only run at submit time.
If a required field is on page 2 but conditional logic has hidden it, the server-side validator will still enforce the required rule and reject the submission. This mirrors the same behavior described in the Conditional Logic gotchas: don’t mark conditionally-hidden fields as required. Either uncheck Required, or use two variants (one required and shown when needed, one optional and shown otherwise) with mirrored conditional rules.
Conditional logic across pages
Conditional logic rules re-evaluate whenever any field changes anywhere in the form, so cross-page rules work in principle. Field on page 3 can be conditional on a trigger from page 1, and when the visitor changes the page 1 trigger, the page 3 target updates immediately. Everything is in the same DOM the whole time.
But there’s a directional gotcha worth planning around.
If a field on page 1 is conditional on a trigger on page 2, the trigger’s value is empty when page 1 first loads, because the visitor hasn’t reached page 2 yet. Rules like “Show if Country is US” evaluate against empty, fail to match, and the target stays hidden. If the visitor eventually fills page 2 and goes back to page 1, the target updates correctly, but that’s a confusing experience. Structure your form so triggers always live on an earlier page than the fields whose visibility depends on them. This matches the mental model of a wizard: earlier answers determine later questions, not the other way around.
For the full conditional-logic operator reference and setup steps, see Conditional Logic: Show and Hide Fields.
Multi-Page vs Save & Continue
Two features can be confused. They’re related but different, and they compose well together.
| Feature | What it does | When to use |
|---|---|---|
| Multi-Page Forms | Splits one long form into a wizard-style sequence of pages within a single session. The visitor completes and submits in one sitting. | Any form with more than 6 or 7 fields that would feel overwhelming as a single wall. |
| Save & Continue | Persists a partial submission (via unique link or email token) so the visitor can leave the form, return later, and pick up where they left off. Works with or without pagination. | Forms that take 10+ minutes to complete, or need documents / information the visitor doesn’t have on hand. |
The two combine: enable Multi-Page for the wizard UX and Save & Continue for the resumable state, and visitors get both a paced experience and the ability to pause. Save & Continue has its own setup covered in a separate page.
Troubleshooting the four common multi-page issues
1. My form still shows all fields at once instead of paginating
Two possibilities. First, verify you actually added a Page Break field to the form (Layout section of the palette). Without a Page Break, FormForge renders as single-page regardless of how many fields you have. Second, if you did add Page Breaks but they’re all clustered at the very start or very end of the form, they collapse into a single populated page and FormForge renders as single-page. Rearrange so at least one Page Break sits between two groups of real (non-layout) fields.
2. Clicking Next doesn’t advance the visitor to the next page
Almost always a validation failure on the current page. Look for a highlighted required field with an inline error message; that’s what’s keeping the form on the current page. If nothing is visibly highlighted, open the browser console (right-click the form, Inspect, Console tab) and click Next again. A JavaScript error there means a plugin or theme conflict is blocking the multi-page navigation script. Deactivate other plugins one at a time until Next works, then reactivate the culprit and report it to support.
3. Progress bar shows the wrong number of steps
The step count is derived from the number of Page Break fields plus one. If it’s showing more steps than you expect, you probably have an extra Page Break somewhere. If fewer, one of your Page Breaks might have been dragged into a position where it collapses (adjacent to another Page Break, or at the very start of the form). Open the form in the builder, count the Page Break markers in the canvas, and confirm they sit between groups of real fields.
4. The Submit button shows up on page 1 instead of on the last page
FormForge hides the Submit button on initial load of a multi-page form via a small JavaScript snippet, then re-shows it when the visitor reaches the last page. If that JS never runs (jQuery not loaded, a plugin conflict throws an error before the FormForge script executes, an aggressive JS minifier corrupts the file), the Submit button stays visible on page 1 the entire time. Fix: open the browser console on the form page, look for red-text JavaScript errors. If you see any, deactivate other plugins one at a time until the errors clear, then reactivate the culprit and report it to support. If the console is clean but the Submit button still shows on the wrong page, purge your caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, ForgeCache) so any stale JS payload gets rebuilt.
Gather: (a) the number of Page Break fields in the form and where they sit, (b) exact wording of any error the visitor sees, (c) whether Next / Previous respond at all, (d) browser console output on click. Send to support and we can dig in.
FAQ
How do I split a FormForge Pro form into multiple pages?
Drag the Page Break field from the Layout section of the field palette to wherever you want the page to split. Every field before the Page Break lives on page 1; every field after lives on page 2. Add more Page Break fields for more pages. Save the form. The form auto-renders with a progress bar and Next / Previous navigation.
How many pages can a FormForge Pro form have?
As many as you want. Each Page Break field creates one additional page, so N Page Breaks produce N+1 pages. The progress bar renders each page as a numbered step (Step 1, Step 2, Step 3, and so on). Forms with more than four or five pages usually see completion rates drop, so keep the count tight.
Can I rename the Step 1 / Step 2 progress bar labels?
Not in the current release. Step labels render as Step 1, Step 2, Step 3, and so on, auto-generated from the page index. Until custom per-page labels ship, use a Section field at the top of each page to give context to what that page collects. The Section renders as an inline heading the visitor will actually see, which serves the same purpose.
Does validation run on each page or only at the end?
Both. When the visitor clicks Next, the current page’s required fields and email fields validate immediately, so they cannot advance while any required field on the current page is empty. When the visitor clicks Submit on the last page, the server re-validates every field on every page, so nothing slips through.
Can conditional logic reference a field on a different page?
Yes, and rules re-evaluate whenever any field changes anywhere in the form. But there’s a directional gotcha: a rule on page 1 that references a trigger on page 2 will always evaluate against an empty trigger value initially, because the visitor hasn’t reached page 2 yet. Put the trigger field on an earlier page than the field whose visibility depends on it. See the Conditional logic across pages section above.
Why does my form show all fields at once instead of paginating?
Two possibilities. (1) You haven’t added a Page Break field. FormForge Pro renders a form as multi-page only if the form contains at least one Page Break that produces two or more populated pages. (2) All your Page Breaks are consecutive at the start or end of the form, which collapses to a single populated page. Fix: verify a Page Break sits between two groups of real fields.
What happens to files uploaded on page 1 if the visitor navigates to page 2 and back?
The file stays selected. FormForge Pro keeps every page’s fields in the DOM at all times and just shows or hides the container div, so browser file-input selections persist across page navigation. The file uploads with the final form submit on the last page. See File Uploads: Setup and Troubleshooting for the full file-upload flow.
Can I use multi-page forms with payments?
Yes. Payment fields (Stripe, PayPal, product totals) work on any page of a multi-page form, though they’re usually placed on the final page so the visitor sees the total after selecting products and options on earlier pages. See Stripe Integration for the full Stripe setup.