Somebody submitted the application with the wrong phone number. They noticed straight away, emailed to say so, and the reply they got back was a request to submit the form again. Now there are two records for the same person, the newer one is not obviously the newer one once the list is sorted by name, and whoever reviews the batch has to work out which is which.
Editing a submitted Google Forms response is possible, but it depends on a setting that has to be switched on before the response arrives, and on the respondent still having a link that most people close and forget within a minute. The paths below cover what a respondent can do, what the form owner can do, what changing the linked spreadsheet does and does not do, and how to stop the same correction arriving by email next month.
What can be edited, and by whom
Three different things get called editing a response, and only one of them changes the record the form holds.
| Action | Who can do it | What it changes |
|---|---|---|
| Open the edit link and resubmit | The respondent, if editing is allowed | The stored response, in Forms and in the linked sheet |
| Change a cell in the linked spreadsheet | Anyone who can edit the sheet | The sheet only, not the response in Forms |
| Delete the response and ask for a new one | The form owner or an editor | Removes the record and creates a separate one |
The distinction in the middle row causes most of the confusion on this subject. A Google Form and its linked spreadsheet are not two views of the same data. The sheet receives a copy at submission time. Typing over a cell in that copy corrects the spreadsheet and leaves the Forms response, the summary charts and anything reading directly from Forms showing the original answer.
There is no editor role inside Forms that lets the owner open somebody else's submission and correct an answer in place. The owner can read the responses, delete them and export them, and that is the extent of it. Every route to a genuinely corrected response runs through the respondent.
Turning on response editing before you need it
The setting is in the form, not in the response. Open the form, click Settings at the top, click the down arrow next to Responses, and turn on Allow response editing.
Two things follow from where this setting lives.
It applies to the form, not to one person. Once on, everyone who submits gets an editable response, and anyone holding a link can keep changing their answers for as long as the form exists. For a satisfaction survey that is harmless. For a bid, a job application or anything scored against a deadline, it means the submitted answer is not fixed at the deadline, which is usually not what the process assumes.
It is not retroactive in any useful way for people who have already submitted. Turning the setting on later does generate edit URLs for existing responses, but the respondents were never shown them, so somebody has to retrieve and send those links individually. That is a script job rather than a click.
The safe default for most intake forms is to leave editing off and handle corrections as a deliberate step, because an editable record with no history is worse than a fixed record plus a note.
Getting the edit link to the respondent
The edit link appears on the confirmation screen right after submission, under wording offering to edit the response. Almost nobody uses it there, because at that moment they do not yet know anything is wrong.
The link that actually gets used is the one in the emailed copy. Two settings have to line up for that email to exist. Under Responses in Settings, Collect email addresses must be set to either Verified or Responder input, and Send responders a copy of their response must be set to Always rather than When requested. With both in place, every respondent gets an email containing their answers and an edit link, which is the only copy of that link they are likely to still have a week later.
Google's help documentation notes that receipts do not always arrive, since spam filtering and anti-abuse measures can intercept them. That is worth knowing before telling a respondent to check their inbox for a link that may never have landed.
Where the link has genuinely been lost, the remaining route is Apps Script. The Forms service documents getEditResponseUrl() on a form response, described as generating a URL that can be used to edit a response that has already been submitted, and getRespondentEmail(), which returns the submitter's address when email collection is on. A short script pairs the two and sends the right link to the right person, which is also the way to send edit links in bulk after turning the setting on late.
Correcting the data without editing the response
Sometimes the respondent does not need to be involved at all. A typo in a postcode, a phone number entered with the country code in the wrong format, a date written the American way round: these are cleanup, not resubmission.
Editing the linked spreadsheet is the usual way to do it, and it works as long as everybody understands its boundaries. The corrected cell is correct in the sheet, stays correct, and feeds anything downstream that reads from the sheet. The Forms response behind it is untouched, so the summary view and any export taken from Forms will still show the original. Where the two disagree, the sheet is the one people look at and the Forms record is the one that quietly contradicts it months later.
Three habits keep this from becoming a problem:
- Decide which one is authoritative and say so. For most teams that is the sheet, at which point the Forms summary charts should not be used for reporting.
- Do not edit in place without a trace. Add a column for corrections and one for who made them, or copy the original value into a notes column before overwriting. A correction nobody can see is indistinguishable from an error.
- Watch the structure. Inserting or deleting columns in a form-linked sheet, or reordering them, can leave later submissions writing into the wrong place relative to any formulas built beside the data. Formulas that read the response columns should be positioned so that new rows do not collide with them.
The heavier option is deleting the response and asking for a resubmission. It gives a clean record and it loses the original timestamp, which matters wherever order of arrival decides anything. Where a deadline or a queue position is involved, the correction belongs in a note beside the original rather than in a new submission dated after the deadline.
What editing does to everything downstream
A response that changes after submission is a small problem inside Forms and a larger one everywhere the response has already been sent.
When an edited response is saved, the corresponding row in the linked spreadsheet updates in place. The timestamp of the original submission stays, so an edit made three weeks later is invisible in the data unless something else recorded it. That is the single most useful thing to know before allowing editing on a form whose answers trigger anything.
Anything already triggered by the first submission does not rewind. A notification email that went out on submission contains the old answers. A document generated from the response holds the old answers. A task created in another system, a calendar invitation, a message posted to a channel: all of them carry what was true at the time, and none of them are updated by the edit. In practice this means a form with editing on and automation attached will produce disagreements between systems, and the edit will usually be the version nobody downstream saw.
File upload questions behave differently again, because they require the respondent to be signed in to a Google account, and the uploaded file lives in Drive rather than in the response. Editing a response to replace a file leaves the earlier upload in place.
The same applies to anything a person did with the response by hand. If a reviewer has already read the submission, scored it and written a reply, an edit arriving afterwards does not reopen any of that. The reviewer sees a corrected record only if they happen to look again, and nothing in the form flags that the record moved. On a small batch somebody usually notices. On two hundred submissions being worked through over a fortnight, nobody does.
A workable compromise on forms that genuinely need both editing and automation is to allow edits only during a short window and say so in the confirmation message. Keep editing on until the deadline, then turn the setting off, which fixes every response in place from that point without deleting anything. The answers stay editable while it is cheap to change them and stop being editable at the moment anything starts to depend on them.
None of this argues against allowing edits. It argues for deciding, per form, whether the answers are a statement at a moment in time or a record that should stay current, and then setting the form to match.
Designing the form so corrections are rare
Most correction requests come from a small number of predictable places, and they are cheaper to prevent than to process.
Response validation on the fields that get mistyped catches the majority: a pattern on phone numbers, an email format check, a numeric range on quantities. Where an answer will be used to contact someone, asking for it twice is crude and effective. Short help text under a date question stating the expected order removes the single most common ambiguity in international intake.
Limit to 1 response is worth a thought here rather than a reflex. It prevents the duplicate submissions that arrive when somebody corrects themselves by starting over, and it requires sign-in, which excludes respondents without a Google account. On a public form that exclusion is usually the larger cost.
The other half is the process rather than the form. Somebody has to notice the correction email, find the original response, apply the change and tell the person it is done. A form tool with response management treats that as the normal path: the response holds an owner and a status, the correspondence sits with the record rather than in one person's inbox, and a corrected record shows that it was corrected. The intakes where this matters most are the ones where each response belongs to a named person and gets an individual answer.
What to change first
Decide for each live form whether answers should stay editable after submission, then set Allow response editing deliberately instead of leaving it at the default. On the forms where editing stays off, turn on email receipts so respondents have a copy to quote from when they write in, and agree where corrections get recorded. If the corrections are already arriving faster than anyone can track them, the fix is a record that carries its own status rather than a tidier spreadsheet, which is what Halict demonstrates per response.
Q1. Can a Google Form owner edit somebody else's response?
Not inside Forms. The owner can view, delete and export responses, but there is no way to open another person's submission and change an answer. The practical options are to correct the value in the linked spreadsheet, which changes the sheet but not the Forms record, or to send the respondent their edit link so they can change it themselves.
Q2. How does a respondent find the edit link after closing the confirmation page?
The link is also in the emailed copy of the response, which only exists if the form was set to collect email addresses and to send responders a copy of their response. Without that email, the link can be regenerated with Apps Script using getEditResponseUrl() on the stored response. Otherwise the remaining option is a fresh submission.
Q3. Does editing a response update the linked Google Sheet?
Yes. An edited response overwrites the existing row rather than adding a new one, and the original submission timestamp stays unchanged. Anything already generated from the first version, such as a notification email or a document, keeps the old answers, so edits and automation need to be planned together.
Q4. Is it safe to type corrections directly into the form's spreadsheet?
It works, with one caveat: the correction exists only in the sheet, and the response stored in Forms still shows the original. Pick one of the two as authoritative, record what was changed and by whom, and avoid inserting or deleting columns in the response range, since new submissions keep writing to the original column positions.
Q5. Should response editing be turned on for an application or registration form?
Usually not. Editing means the answer at review time may differ from the answer at the deadline, with nothing in the data showing that it changed. For surveys and internal requests it is convenient and low risk. For anything scored, ranked or queued, handling corrections as a tracked step keeps the record defensible.