Overview
Sometimes a form appears to have been submitted more than once, even though the visitor only clicked the submit button once. Gravity Forms uses several layers of protection to reduce duplicate entries, depending on the cause.
This article covers three scenarios: reloading the page or restoring a browser tab after a successful submit, clicking Submit multiple times while the form is still processing, and submitting the same unique value more than once.
Why duplicates happen
Browser resubmission after page reload
When a visitor submits a form, the browser sends the form data to your site as a POST request. If the visitor stays on the confirmation screen and then refreshes the page, or returns to the tab later and reloads the browser, the same request may be resent. This can happen with or without a visible warning prompt, depending on the browser.
Multiple clicks during a slow submission
If a submission is slow due to a payment process, file upload, or CAPTCHA check, a visitor may click Submit or Next multiple times while waiting. Each click can trigger another submission unless the form blocks or ignores the extra attempts.
Repeated submissions with the same value
A visitor submits again with the same email address, username, or ID. That is a data duplicate rather than a browser or double-click issue, and is handled separately through the No Duplicates field setting.
Multiple layers of protection
Gravity Forms protects against duplicates through three independent mechanisms:
Reload protection
After the server saves an entry and displays the confirmation, Gravity Forms runs a small script in the background. The script updates the browser’s address bar so that a normal page refresh is treated as loading the page, not resending the form. This protection applies automatically and is on by default.
The script only runs after a successful submission. Failed validation or an interrupted submit does not trigger it.
Safari on desktop and iOS
Safari, including Safari on iPhone and iPad, handles page history and reloads differently from Chrome and Firefox, so Gravity Forms takes a slightly different approach for it. After a successful submission in Safari, a query parameter is added to the URL in the address bar:
?gf_protect_submission=1
This marks the confirmation URL as already submitted. If Safari tries to reload the page in a way that would resubmit the form, Gravity Forms intercepts the request on the server and redirects the visitor back to the form page without that parameter, so they get a normal page load instead of a duplicate entry.
You may briefly see ?gf_protect_submission=1 appear in the address bar on Safari immediately after submission. That is expected behavior and does not indicate a problem.
Multiple clicks while the form is processing
This is handled separately from the reload protection above. When a visitor clicks the Submit or Next buttons, Gravity Forms immediately treats the form as already submitted, so additional clicks during a slow request do not trigger another full submission.
For AJAX-enabled forms, the submission stays on the same page throughout the form and is replaced with the confirmation once the server responds, further reducing the chance of duplicate entries from a refresh.
No Duplicates field setting
If a particular field, such as an email address or registration ID, should only ever appear once across all entries, you can enable the No Duplicates option for that field under its Advanced settings in the form editor.
When the form is submitted, Gravity Forms checks existing entries for that value. If a match is found, validation fails, and an error message is shown to the visitor. This check happens on the server and is independent of the reload protection and multiple-click handling described above. For more details on the setting, see Duplicate Submissions and No Duplicates.
Troubleshooting
Use a redirect confirmation when your flow allows it. Sending visitors to a new URL after submit sidesteps most reload-related duplicate scenarios. Avoid aggressive caching on pages that host forms or display confirmations. Enable No Duplicates on any field that must be unique. And where possible, let visitors know to wait for the spinner or confirmation message before clicking again.
| Symptom | Things to check |
|---|---|
| Duplicate entries after refreshing the confirmation page | Using a message confirmation on a cached page; try switching to a redirect confirmation or disabling caching for that page |
?gf_protect_submission=1 appears in the URL on Safari | This is part of Safari’s duplicate protection; a reload should return a normal page without creating another entry |
| Duplicate entries from rapid clicking | Check for JavaScript errors on the page; confirm AJAX submission is enabled; check for custom submit buttons or plugins that replace the default button |
| Same email address or ID submitted more than once | Enable No Duplicates on the relevant field, or review whether resubmissions are intentional and should be allowed |
Developer reference
The duplicate submission protection feature is handled by GF_Duplicate_Submissions_Handler in includes/duplicate-submissions.php.
Protection only applies to requests that include the gform_submit POST field. When a submission is successful, meaning an entry ID is present, PHP enqueues js/duplicate-submissions.js and passes it a flag confirming the submission was valid. If validation failed or the submission was interrupted, the script is a no-op.
Note: The script calls history.replaceState to update the browser’s address bar so a subsequent refresh is treated as a normal page load rather than a POST resubmission. On Safari, instead of a clean URL, it sets ?gf_protect_submission=1. If Safari then navigates to that URL in a way that would resubmit the form, maybe_handle_safari_redirect intercepts it early in the page load, and issues a 303 redirect back to the form page without the parameter.
To disable protection globally or per form, use the gform_is_disabled_duplicate_submissions_protection filter.