A test submission sits at the top of the list from the afternoon the form was built. Two rows below it, somebody pressed submit twice. Further down, a real response that has to come out because the person who sent it asked for it to be removed. Three different reasons, one search, and a form interface that offers exactly two delete controls, neither of them where most people look first.
Both controls are easy to find once you know they exist. The part worth getting right is what each one touches, what it leaves behind in the linked spreadsheet, and which of the two is impossible to walk back.
Where the two delete controls actually are
Google Forms separates the response views into a Summary tab and an Individual tab, and the delete controls live in different places on each.
Removing one response
Open the form, click Responses at the top, then open the Individual tab. Google's own instruction for finding the one you want is to click Previous or Next, which is fine for a form with twelve responses and painful for a form with four hundred. The down arrow beside the response counter opens a list you can jump through, which is faster. Once the right response is on screen, click the trash icon and confirm.
Removing everything
Open the form, click Responses, stay on the Summary tab, open the three dot menu at the top right, and choose Delete all responses. Confirm with OK.
One detail catches people out here. The Summary tab appears on a form only when there is at least one response. If the tab is missing entirely, the form has nothing stored, and whatever you are looking for is somewhere else: an old copy of the form, a different account, or a spreadsheet that was unlinked.
There is no middle setting
That is the complete set of controls. No checkbox column, no shift click across a range, no way to say "these eleven from Tuesday". The gap between deleting one response and deleting every response is where every workaround in the search results comes from, and where most of the accidents happen. Somebody with sixty test submissions mixed into three hundred real ones reaches for Delete all responses because clicking through sixty individual confirmations is unbearable, and the three hundred go with them.
The spreadsheet is a separate file, and it behaves like one
This is the fact that changes how you should sequence the work. Google states it plainly: if you store responses in a spreadsheet, you have a separate file in Google Drive, and you can delete the spreadsheet without deleting the form, or delete the form without deleting the spreadsheet.
Two files, two sets of data, one link between them that can be cut at any time. Unlinking is a supported action: from the Responses Summary tab, the three dot menu offers Unlink form, and Google describes the result as new responses no longer being sent to the spreadsheet while the current data remains intact. The reverse operation exists too, through Select destination for responses, which lets you create a new spreadsheet or point the form at an existing one.
The practical consequence is that after any deletion you should look in both places before believing the job is finished. A response you removed from the form's Individual tab and a row sitting in the sheet are not the same object, and the team that works from the sheet will keep seeing what the form no longer shows.
Before deleting anything, take a copy. From the Responses tab, the three dot menu includes Download responses (.csv). That file costs nothing to keep and is the only version of the data that survives a mistake. If the team works from the linked sheet, make a copy of the sheet as well, since a copy is a genuinely separate file rather than a view of the same rows.
What cannot be undone
Google's wording on this is short and absolute: if you delete any responses in a form, it cannot be undone.
There is no trash for responses. There is no version history covering the form's response store the way version history covers a document. Ctrl+Z does nothing after the confirmation dialog closes. The undo paths people reach for after the fact are all indirect, and each one depends on something you did earlier:
- The linked spreadsheet, if it was connected at the time the responses arrived and nobody deleted the rows.
- A CSV exported before the deletion.
- Notification emails, if email notifications for new responses were turned on, since each one carries the content of a submission.
- The response receipt in the responder's own inbox, if the form was set to send responders a copy of their response.
None of these is a restore. They are reconstruction, and reconstruction of two hundred rows from two hundred emails is a day of work. The five seconds spent on a CSV export beforehand is the entire insurance policy.
Choosing the right route for the reason you came
The correct action depends on why the response has to go, and the four common reasons pull in different directions.
| Reason | Use this | What stays behind |
|---|---|---|
| A handful of test submissions | Individual tab, delete one at a time | Nothing in the form. Rows stay in the sheet unless you delete them there |
| Clearing the form to reuse it next term or next season | Export CSV, then Delete all responses | The CSV, plus whatever is in the old sheet |
| Starting a fresh cycle but keeping history visible | Unlink form, then create a new destination spreadsheet | The old spreadsheet, complete and readable |
| A removal request from the person who submitted | Delete in the form, then handle the sheet, uploads and exports separately | More than you expect. See below |
The third route is worth more attention than it gets. Unlinking and pointing the form at a new spreadsheet gives a clean slate for the next cycle without destroying anything, which is exactly what most people clearing a form actually want. The old sheet keeps its data, stays searchable, and can be filed away.
A removal request is not one delete
When somebody asks for their submission to be taken out, deleting the response in Forms is the first step of four, and the other three are easy to forget.
The linked spreadsheet holds its own row. Anyone who exported a CSV during the week has a copy on a laptop. If email notifications were on, the content of the submission is sitting in one or more inboxes. And if the form contains a file upload question, the uploaded files are stored in a new folder on the form owner's Google Drive, which is a separate location again.
Write the list down once and keep it with the form. The point is not thoroughness for its own sake. It is that a request handled halfway looks identical from the outside to one handled properly, right up until the person asks why their attachment is still visible.
When the delete controls are not there at all
A form that has collected responses for years can reach a state where the controls described above simply do not appear, and the usual conclusion is that something is broken. It is not. Google publishes a set of response volume thresholds, and past each one a different part of the interface stops working while the form keeps accepting submissions.
Past 10,000 responses, the question view and the individual view for responses stop appearing in Forms. That is the view the single response delete button lives in, so on a very large form there is no way to remove one response through the interface at all. Past 50,000 responses, the response summary stops appearing, which takes the Summary tab and the Delete all responses menu item with it. Past 100,000 responses, responses stop syncing to Sheets.
Google's guidance in all three cases is the same: the form continues to receive responses, and they can be downloaded as a CSV file. Deletion, at that size, is not a maintenance task you perform on the existing form. The realistic move is to export everything, close the old form to new responses, and publish a fresh one, pointing it at a new destination spreadsheet.
If a form is anywhere near those numbers, that is also a signal in itself. A response store large enough to break its own interface is being used as an archive, and an archive is a different job from an intake queue.
Why delete gets used as a status marker
Look at how the button is actually used and a pattern shows up quickly. People delete responses they have finished dealing with. Not because the data is wrong, and not because anybody asked, but because the list has no other way to show that a submission has been handled. The response list treats every entry identically from the day it arrives until the day it is removed, so removal becomes the only available signal that something is done.
That is a workflow problem wearing the costume of a data problem, and it has a cost. A deleted response cannot be counted at the end of the quarter, cannot be checked when the person writes back three weeks later, and cannot be used to show that the reply was sent. The tidy list is bought with the record.
The alternative is a response list where each entry carries a status and an owner, so that finished work is visibly finished and still there. Any tool built around managing responses rather than collecting them does this, and it is usually the single feature that ends the habit of deleting things to keep the view clean. If the pattern sounds familiar, it is worth looking at how teams handle intake that continues after submit before adding another column to a spreadsheet.
Two habits that prevent most of the damage
The first is exporting before deleting, every time, without judging whether this particular deletion is risky. Judging is where mistakes come from. The export takes one click and the file goes stale harmlessly.
The second is separating testing from collecting. Build and test on a copy of the form, then publish the original. A form that has never received a test submission never needs the cleanup that leads people to Delete all responses with three hundred real responses in the list.
What to change first
If test data is the reason you came here, delete those responses individually today and move your testing to a duplicate form so the problem does not come back. If you are here because the response list has become unreadable, the answer is not deletion at all. Give each response an owner and a status so finished work can stay in the record, which is what Halict and tools built the same way are for.
Q1. Can you delete multiple Google Form responses at once without deleting all of them?
Not through the Forms interface. The only two controls are deleting one response from the Individual tab and deleting every response from the Summary tab. Teams with a large cleanup usually export a CSV, delete all responses, and re-import the rows worth keeping into a spreadsheet, or unlink the form and start a new destination sheet instead.
Q2. Does deleting a response in Google Forms remove the row from the linked spreadsheet?
Treat them as two separate files, because that is what they are. Google states that a linked spreadsheet is a separate file in Google Drive and that either one can be deleted without the other. Check the sheet yourself after deleting in the form, and delete the row there as well if the team works from the sheet.
Q3. Can a deleted Google Form response be recovered?
No. Google's documentation states that deleting responses in a form cannot be undone, and there is no trash or version history for the response store. Recovery is only possible from something saved earlier: a linked spreadsheet, a CSV export, notification emails, or the response receipt in the responder's own inbox.
Q4. How do you clear a form's responses to reuse it next year?
Download the responses as a CSV from the three dot menu on the Responses tab, then use Delete all responses. If you would rather keep the old data live and readable, unlink the form instead and use Select destination for responses to create a new spreadsheet, which leaves the previous sheet complete.
Q5. Someone asked me to remove their submission. Is deleting the response enough?
Usually not. The row in the linked spreadsheet, any CSV that was exported, notification emails sent when the response arrived, and any file the person uploaded all sit outside the form. Uploaded files in particular are stored in a folder on the form owner's Google Drive and have to be removed there.