How to let users save form progress in WordPress

Decide whether users only need to return on the same browser, or whether they need a link that works on another device. Browser storage is suitable for simple, low-risk forms and guest visitors. Server-side drafts are better when users need email links, account-based access, staff follow-up, or recovery across devices.

Do not save passwords, payment details, or other sensitive values in browser storage. Also check how your form plugin handles file uploads, because some save-and-continue systems exclude uploads and other special fields from drafts.

Open the form’s settings and look for a feature named Save and continue, Save progress, Save draft, or similar. Enable it, add the save control to the form, and configure the return method offered by the builder, such as an email link, a confirmation message, or a saved-drafts list.

For a multi-step form, save after each step as well as when the visitor clicks the save control. Confirm that the form restores both the entered values and the current step. Multi-step navigation alone does not save a visitor’s work after they leave the page.

If your form plugin has no save feature and same-device recovery is enough, add a small custom script that serialises non-sensitive field values to the visitor’s browser as they type. Restore those values when the form loads, and provide a visible Clear saved data control.

This is the manual route, but it has important limits: the data is tied to that browser and device, can disappear when storage is cleared, and is not available to staff on the server. It also needs careful handling for checkboxes, radio buttons, select fields, multi-step state, expiry, and fields that should never be stored.

For cross-device recovery, create a draft record on the server and associate it with a logged-in user or a long, random resume token. Store only the fields needed to restore the form, validate and sanitise every value, protect save and load requests against forgery, and expire abandoned drafts.

WordPress provides temporary storage through the Transients API and user-specific storage through user metadata, but you still need to write the form endpoint, permissions, token handling, validation, restoration logic, and deletion process. WordPress post autosave is intended for posts, not an arbitrary front-end form.

Test saving halfway through the form, closing the tab, returning later, using the resume link in a private window, opening it on another device, and submitting the completed form. Test logged-in and guest visitors separately.

Check what happens when a draft expires, a user saves twice, two tabs edit the same draft, the email is delayed, JavaScript fails, or the form structure changes. Make the expiry period and privacy notice clear. A save link that exposes a draft to anyone who obtains it is a security issue, so use unpredictable tokens and avoid putting sensitive data directly in the URL.

The fast route is to use JetFormBuilder Save Form Progress with a JetFormBuilder form. It adds browser-specific save-and-resume links for long or multi-step forms, including guest users, so you do not have to build the storage, return-link, and restoration workflow yourself.

Install and activate the add-on, configure the save control and return-link behaviour, then test the form as a guest and as a logged-in user. Confirm which fields and uploads are included before using it for sensitive or legally important information.