The link appears on the confirmation screen after somebody sends a form: a short line inviting them to submit another response. It looks harmless. It is also the single setting that decides whether the form collects one row per person or one row per attempt, and that decision lands on whoever has to work through the responses afterwards.
Most of the confusion around it comes from a reasonable assumption: that a second submission replaces the first. It does not. The link opens a fresh, empty copy of the form, and what arrives is a completely separate response with its own timestamp. Nothing is matched, nothing is merged, and nothing warns the person reading the sheet that two rows describe the same person.
What the link actually does
Clicking the link reloads the form with blank answers. The earlier submission stays exactly where it is. The new one is appended as a new response, which is why a form that has been open for a month can hold three rows from the same address, all slightly different, with no marker saying which one counts.
Google's own response views reflect this. In the Responses tab, the Individual view shows answers by person, or, as the documentation puts it, "by submission" when people have been allowed to submit the form more than once. The distinction is visible in the interface because it is real: the form is no longer holding a set of respondents, it is holding a set of events.
That is not a defect. For some intake, events are the right unit. A daily equipment check, a shift report, a defect log, a room booking request: each submission is its own thing, and the same person sending fifteen over a month is normal and correct. In those cases the link is doing useful work, because it saves the responder from navigating back to the form URL.
The mismatch appears when the unit is people. Applications, registrations, membership requests, grant submissions, support requests about one continuing problem. For those, a second submission usually means one of three things: the first attempt was wrong, an attachment was missing, or the person is not sure the first one arrived. All three are corrections, and none of them are new applications, but the form records all three identically.
Where the setting lives, and what sits beside it
The options that govern this behaviour are in the form's Settings tab, not in the question editor. Two sections matter.
Under Responses, expanding the section reveals Limit to 1 response and Allow response editing. The first prevents more than one submission per person, and Google is explicit that it works by requiring people to sign in to a Google account, because there is no other way to tell one responder from another. The second lets a responder return to what they already sent and change it, which is the closest thing Google Forms offers to a correction path.
Under Presentation, the section holds View results summary and the Confirmation message, which has its own Edit control. The confirmation message is the screen the resubmission link appears on, and it is the place to say something useful rather than leaving the default text to do the work.
Two consequences follow from how these are built. Requiring sign-in to enforce one response per person shifts a cost onto the responder: anyone without a Google account, or signed into the wrong one on a shared or public machine, is blocked at the point of submission. And response editing depends on the responder keeping the edit link they were shown, which means it works well for people who read confirmation screens carefully and badly for everyone else.
Second response, or edited response
These are the two shapes available, and they behave very differently on the receiving side.
| Second response | Edited response | |
|---|---|---|
| What arrives | A new row, new timestamp | The original row, changed in place |
| History of the change | Both versions kept | Earlier answer overwritten |
| Setting involved | Resubmission link on the confirmation screen | Allow response editing |
| Needs sign-in | No | No, but the responder needs the edit link |
| Main risk | Duplicate rows nobody has reconciled | Silent change to a row somebody already acted on |
Keeping both versions sounds safer, and for anything with an audit trail it is. The cost is that the reconciling never happens by itself. Someone has to decide which row is current, and that decision has to be recorded somewhere the next person will see it, otherwise the same question gets answered twice.
Editing in place avoids the duplicate and introduces a quieter problem. A response that was already read, scored or forwarded can change afterwards with no notification. Where a response triggers real work, an edit that arrives after that work has started is worse than a duplicate, because a duplicate is at least visible.
There is no setting that resolves this. What resolves it is deciding, before the form is published, whether the form is collecting events or people, and then choosing the option that matches. Reviewing how other teams frame that choice for applications, bookings and support intake is a faster way to decide than reasoning about it in the abstract, which is what the use cases pages are for.
What a second submission does to your spreadsheet
Responses reach a sheet through the Responses tab, where Select destination for responses offers either "Create a new spreadsheet" or "Select existing spreadsheet". Every submission appends a row. There is no key, no upsert, no match on email address.
So the deduplication work moves into the sheet, and it is usually one of these:
A helper column that flags repeat email addresses, which only works if the form collects email addresses in the first place. Sorting by timestamp and treating the latest row per person as authoritative, which is fine until two rows carry different answers to different questions and the older row holds an attachment the newer one does not. Or a manual status column, which works well and stops working the moment more than one person maintains it, because two people editing the same cell is not a conflict the sheet resolves for either of them.
Two further details are worth knowing. Unlinking the sheet, through Unlink form, stops new responses flowing to it while leaving existing data in place, so an unlinked sheet quietly goes stale rather than breaking. And deleting responses inside the form is permanent: Google states plainly that if you delete responses in a form, it cannot be undone. Cleaning up duplicates on the form side is therefore a one way operation, and the safer habit is to mark rows in the sheet rather than delete them in the form.
Limits that arrive before you expect them
Allowing resubmission multiplies the number of responses a form holds, and Google Forms has documented thresholds where parts of the interface stop working. All four are worth knowing in advance, because none of them announce themselves.
| Threshold | What stops working |
|---|---|
| More than 10,000 responses | The question and individual views are no longer available |
| More than 10,000 responses | CSV downloads are no longer sorted by submission timestamp |
| More than 50,000 responses | The response summary is no longer available |
| More than 100,000 responses | Responses no longer sync with Sheets |
The second one deserves attention from anyone relying on the latest row per person, because that approach assumes the export is ordered by time. Above 10,000 responses the CSV is not, and a process built on that assumption produces wrong answers rather than an error.
The spreadsheet has its own ceiling. Google's documentation lists up to 20 million cells or 100MB for spreadsheets created in or converted to Google Sheets. A wide form with file upload questions and a long response history reaches that sooner than a narrow one, and the failure mode is a sheet that becomes slow to open well before it refuses to accept anything.
Turning the link off, and what happens next
Removing the resubmission link is a reasonable choice for people based intake, and it changes behaviour rather than eliminating it. Someone who believes their submission failed will still try to correct it. Without a link, the attempts arrive as email to whichever address is on the form, or as a phone call, or as a second submission made later from the form URL they still have in their history.
Two adjacent settings shape how often that happens.
Autosave. When someone fills in a form while signed into a Google account, progress is saved automatically as a draft for 30 days. It does not work offline, and the form owner can switch it off. For long forms this is the setting that prevents most accidental resubmissions, because the usual cause of a partial duplicate is a browser closing halfway through.
Accepting responses. Turning this off closes the form, and responders see a message stating that the form is no longer accepting response. Closing a form does not stop people needing to correct what they sent, so a closed form with no stated alternative route produces email to a personal address, which is the least trackable outcome available.
The confirmation message is where this gets managed. Stating what happens next, roughly when a reply should be expected, and what to do if something was wrong removes most of the uncertainty that drives repeat submissions in the first place.
The decision underneath the setting
Resubmission is a symptom worth reading. A form that collects many duplicates is usually a form where the responder cannot tell whether their submission was received or accepted, and the resubmission link is the only feedback channel available to them.
Solving that inside the form has a ceiling, because the form's job ends at the confirmation screen. What the responder wants to know is the state of their submission, and what the person receiving it needs is the same thing from the other side: which responses are handled, who is handling each one, and which ones have been superseded. A sheet can carry that as extra columns. A tool built for response management carries it as a state per response, which is the difference between a tracker that is maintained and one that is kept up to date by the work itself. The features page is the fastest way to see which of those columns stop being manual.
What to change first
Decide whether the form is collecting events or people, then set the resubmission link and the response editing option to match, and rewrite the confirmation message to say what happens next. If duplicates are already in the sheet, add a status and an owner per response before cleaning them up, since the reason the duplicates went unnoticed is that nothing recorded which one was handled. Seeing that shape in a working queue takes a couple of minutes in the Halict demo.
Q1. Does submitting another response in Google Forms overwrite the first one?
No. The link opens a blank copy of the form and the earlier submission stays as it is. The new submission is stored as a separate response with its own timestamp, and the individual response view shows the entries by submission rather than merging them by person.
Q2. How do you stop people submitting a Google Form twice?
Use Limit to 1 response in the Responses section of the Settings tab. Google requires responders to sign in to a Google account for this, because signing in is what identifies one responder from another, so anyone without an account will be blocked at submission.
Q3. Can someone correct a submission without sending a whole new one?
Yes, if Allow response editing is enabled in the Responses section of the Settings tab. The responder edits the row they already sent, which avoids a duplicate but overwrites the earlier answer with no notification to anyone who has already acted on it.
Q4. Why is my Google Form response summary missing?
A form holding more than 50,000 responses no longer offers the response summary. The question and individual views stop being available above 10,000 responses, and responses stop syncing with Sheets above 100,000, so a form that has been open a long time loses parts of the interface rather than reporting an error.
Q5. How do you find duplicate submissions in the response sheet?
Every submission appends a new row, so duplicates have to be found in the sheet: usually by collecting email addresses and flagging repeats, then treating the most recent row per person as current. Above 10,000 responses a CSV export is no longer sorted by submission timestamp, so any process that assumes the newest row is last needs to sort explicitly.
Q6. Is filling in a long Google Form saved if the browser closes?
When a form is filled in while signed into a Google account, progress is saved as a draft for 30 days. Autosave does not work offline and the form owner can turn it off, and an interrupted form with no saved draft is one of the common reasons a half complete duplicate arrives later.