The setting exists, it is one switch, and it works. The reason to read further is that it does not enforce the rule most people think they are buying. Limit to 1 response enforces one submission per signed in Google Account, which is a narrower thing than one submission per person, and it charges for that in a currency some intakes cannot pay.
Knowing the difference before the form goes out is cheaper than finding it in the response list afterwards.
What the switch actually does
The control lives in Settings, under Responses, as Limit to 1 response. Google's documentation attaches one condition to it, and the condition is the whole story: to open and fill in the form, respondents must sign in to their Google Account. Their username is not recorded unless email collection is switched on separately, so the form can still be effectively anonymous to the owner while being identified to Google.
That is a clean design. Uniqueness has to be anchored to something the form can check, and the only thing Google Forms can check is the account in the browser. An email address typed into a text box cannot be checked at all, which is why the setting does not offer that route.
The cost is a sign in wall. Every respondent now needs a Google Account, needs to be signed in to the right one, and needs to be willing to be identified to Google in order to answer. For an internal form inside a Workspace domain, that costs nothing, because everyone is already signed in. For a public intake, a community survey, a suggestion box, or a form aimed at the general public, it is the single largest cause of abandoned submissions that a form owner can introduce with one click.
There is a second, quieter effect. A signed in respondent can be shown the form's existing responses if the summary is switched on, and can edit a submission if response editing is switched on. Neither is the point of the uniqueness setting, but both become available in a way they are not for anonymous forms, so it is worth deciding about them at the same time.
Who gets shut out, and how it looks from their side
A sign in wall does not present itself as a sign in wall. The person who cannot get in usually reports something vaguer: the link did not work, or the form asked them to log in to something they do not have.
Four groups run into it repeatedly. People with no Google Account at all, which in some countries and some age groups is a large share of any public audience. People on a shared or work device who are signed in to an account that is not theirs, and who submit as somebody else without noticing. People whose employer or school restricts what their account can reach. And people on a phone where the default account belongs to a family member.
None of that shows up in the response list, because a response that never happened leaves no row. The only symptom is a lower count than expected, which is easy to attribute to a lack of interest.
If the real requirement is to keep the form to a known group rather than to one submission each, a different control fits better. Publishing a form now includes responder access, where a form can be restricted to named people, to groups, or to target audiences, and access can be given an expiration date. Google extended these granular controls to all forms in January 2026. Restricting who can open the form and limiting how many times each of them can answer are separate switches, and the first one is often the one that was actually wanted.
Three ways one person still becomes two rows
Turning the setting on does not end duplicate submissions. It ends one specific route to them.
A second account. Anybody with a personal address and a work address has two ways past a per account limit, and neither requires ill intent. Someone who filled the form at work and then could not find their answer will often try again at home.
An unverified email field. The Google Forms API describes two ways a form can capture an address. In the verified mode, the address comes from the signed in account. In responder input mode, it is a field the respondent completes, and nothing checks it. Google also notes that for verified collection, respondents have to agree to their Google Account address being recorded with their response, with the confirmation shown on each page of the form. A typed address is text. Two spellings of one address are two people as far as any spreadsheet is concerned.
A correction that arrives as a new submission. This is the most common duplicate of all and the least talked about. Someone submits, spots a typo in their phone number, and submits again. The uniqueness setting blocks the second attempt and produces an email instead. Allow response editing, in the same Responses settings, is the switch that lets a correction land on the original row rather than beside it.
| Control | What it stops | What it does not stop |
|---|---|---|
| Limit to 1 response | A second submission from the same signed in account | A second account, or a second person on the same device |
| Collect email addresses, verified | Anonymous submissions from within the account's reach | One person answering from two accounts |
| Collect email addresses, responder input | Nothing, by itself | Typos, aliases, and deliberately wrong addresses |
| Responder access and expiration | People outside the named group or after the date | Repeat submissions by people inside it |
| Total response limit | Intake continuing past a chosen number | Uneven distribution between respondents |
When one response per person is the wrong rule
There is a class of intake where uniqueness looks right on the form and is wrong in the work. A parent applying on behalf of two children. A supplier quoting for three jobs. A resident booking two different facilities. A customer with a second, unrelated enquiry a month later. In each case the same account legitimately needs to submit twice, and a form that refuses converts a two minute task into an email thread.
The tell is in how the rule is described. "One entry per person" is a fairness rule and belongs on the form. "One record per person" is a data rule and belongs in whatever holds the responses. Enforcing a data rule at the door is what produces the awkward cases, because the door cannot see the difference between a duplicate and a second, distinct request.
For the genuine fairness cases, which are mostly ballots, giveaways and limited places, the per account limit is the right tool and the sign in cost is worth paying. For everything else, the better shape is to let people submit and to handle identity where the responses are read.
One further test helps when the choice is close. Ask what should happen to the second submission if it arrives anyway. If the answer is that it should be discarded without anybody reading it, the rule is a fairness rule and blocking it at the door is correct. If the answer is that somebody should look at it, compare it with the first one, and decide, then the door is the wrong place for the decision, and the restriction is simply moving the work into an inbox where nothing is recorded and nobody owns it.
Finding the duplicates that are already there
Most forms that need this setting have been running for a while without it, so the first useful task is not a setting change at all. It is finding out how big the problem actually is, because the answer decides whether a sign in wall is worth its cost.
Working from the responses as they stand, three passes cover nearly everything. Sort by email address and look for adjacent rows that match: those are the plain duplicates, and a count of them tells you the scale. Then sort by timestamp and look for pairs from the same address within a few minutes of each other, which are corrections rather than second requests, and which tell you whether response editing would have prevented them. Finally, scan the pairs with different addresses but the same phone number or the same name, which is where one person with two accounts shows up.
What comes out of that is a ratio, and the ratio is the decision. A handful of duplicates in a large intake is cheaper to handle by hand than a sign in wall would be in lost submissions. A quarter of the rows being repeats is a structural problem that no amount of careful reading will fix.
The same exercise answers a question that gets asked in the abstract and is better answered with the data at hand: whether the duplicates are people trying to get an advantage, or people who could not tell whether their first attempt had worked. The second cause is far more common, and it is fixed by a clearer confirmation message and a copy of the answers sent back to the respondent, not by a restriction. A form that visibly acknowledges a submission collects fewer of them.
Handling duplicates instead of forbidding them
Handled well, a duplicate is not a problem. It is two rows that need to be one person, and the tools for that live after submission rather than before it.
Three things make it routine. A list that groups submissions by email address, so a repeat answer attaches to a person who already exists rather than arriving as a stranger. An owner on each response, so two people do not reply to the same submitter separately. And a status, so the second submission can be marked as a correction or a duplicate and the first one closed, with both kept for the record.
That is what a form tool with response management provides, and the reason it is worth looking at before switching on a sign in wall: it removes the need for the wall in most cases. Contacts keyed on the email address turn repeat answers from one person into one entry with a history. The use cases for recruitment, enquiries and facility booking all involve the same person coming back, which is precisely the pattern that a per account limit handles badly. It also stays practical as volume grows, since pricing that counts people on the team rather than responses received does not penalise the extra rows that duplicates create.
What to change first
Decide which rule the form is really enforcing. If it is fairness for limited places, turn on the per account limit and accept that respondents need a Google Account. If it is clean records, leave the door open, turn on response editing, and put the deduplication where the responses are read, which is what Halict does with contacts keyed on the email address.
Q1. Can a Google Form be limited to one response without making people sign in?
No. Google's documentation states that respondents must sign in to their Google Account to access and fill in a form with the one response limit turned on. Any other approach, such as asking for an email address in a field, relies on text the respondent types and can be repeated.
Q2. Does the setting record who answered?
Not by itself. Google notes that usernames are not recorded unless email collection is also switched on. Verified email collection records the signed in account's address and asks the respondent to confirm that on each page of the form.
Q3. What happens when someone tries to submit twice?
The second attempt is refused rather than saved, and the respondent is told the form only accepts one response. Most people then send an email instead, which is why turning on response editing is worth doing at the same time, so a correction can land on the original submission.
Q4. Will the limit stop someone using two Google Accounts?
No. The limit is per account, so a personal address and a work address count as two respondents. Where that matters, the workable check is a review of the responses after they arrive rather than a setting on the form.
Q5. Is restricting who can respond the same as limiting responses per person?
They are separate controls. Responder access limits who can open the form, to named people, groups or target audiences, and can be given an expiration date. The one response limit governs how many times each of those people can submit.
