No. A Google Form containing a file upload question requires every responder to sign in to a Google Account, and there is no setting that turns this off. Google states it directly in the documentation for question types: to answer this question, responders need to sign in to a Google Account.
That is the short answer, and if the form is going to the public, it is also a business problem rather than a technical one. Everything below is about the size of that problem and what the realistic alternatives cost.
What Google actually specifies
The file upload question comes with three published conditions, and all three matter when deciding whether to keep it.
Responders must sign in. Not optional, not conditional on other settings, and not something an administrator can relax for a particular form.
The files land on the form owner's Drive. Google describes it as uploaded files being stored in a new folder on Google Drive for the form owner. That folder belongs to the account that created the form, which is a detail worth checking before the person who built the form changes jobs.
The question type is not always available. Google lists two cases where it cannot be used at all: when the form is stored in a shared drive, and when your administrator turns on Data Loss Prevention. Teams that keep everything in shared drives on principle discover the first one at the worst moment, when the form is otherwise finished.
There is a fourth consequence that shows up later. A form containing a file upload question cannot be embedded in an email. Google lists file upload questions alongside rating questions, images in questions or options, and secured quizzes as content that prevents email embedding. If the plan was to mail the form directly to a list, adding an upload field quietly removes that option.
The sign in prompt is not always the upload
Before redesigning anything, confirm which setting is causing the prompt, because several do and they are fixed differently.
Limit to 1 response. Google's note on this setting is explicit: to access and fill out the form, users must sign in to their Google Account. Teams turn this on to stop duplicate submissions and then blame the upload field for the login screen.
Collect email addresses set to Verified. Verified collection takes the address from the signed in account, and responders have to confirm that their Google Account email address gets collected with their response, with the confirmation shown on each page. Switching to Responder input asks the person to type an address instead, which removes the account requirement at the cost of the address being unverified.
Restricted publishing. A form published to a domain, a trusted audience or a named group of users is by definition asking who the responder is.
The file upload question. The one with no workaround inside Forms.
Work through that list before concluding anything. A form with a login prompt and no upload field has one of the other three causes, and two of them are a single toggle away from being fixed.
How to see what responders see
Open the responder link in a private browsing window with no Google session, on a phone as well as a laptop. That is the only reliable test, because the form behaves differently for the owner than it does for a stranger, and a signed in browser hides the entire problem.
The responder link is available from the Publish and Share controls, or from Preview. Use that exact link rather than the editing URL, since the editing URL requires access regardless of any setting.
What the sign in requirement costs
For an internal form, nothing. Everyone already has an account, they are already signed in, and the requirement is invisible.
For public intake, the cost is real and it arrives in three forms.
People without a Google Account simply stop. They exist in larger numbers than most teams assume, particularly outside the audiences that skew towards Gmail.
People with an account but signed into the wrong one are worse, because they get further before giving up. A phone signed in to a personal account, a work laptop signed in to a corporate account with restrictions, a shared machine with three profiles: each produces a moment of friction at exactly the point where the person has already written their answers.
Corporate and institutional accounts are the third case. An organisation's administrator can restrict what their users can do with accounts outside the organisation, and a supplier or applicant may be unable to sign in to anything at all from their work machine.
None of that means the requirement is wrong. It means the requirement should be a decision rather than a side effect of picking a question type.
The four ways teams work around it
| Approach | What the responder does | What it costs |
|---|---|---|
| Ask for a link instead of a file | Uploads to their own storage, pastes a share link | Broken permissions, dead links later, no copy of your own |
| Collect files by email afterwards | Submits the form, then replies to a message with the file | Two steps, and files scattered across an inbox |
| A third party add-on or embed | Uploads through a different tool's interface | Another tool to maintain, and files stored somewhere new |
| A form tool without the requirement | Uploads directly, no account | Moving the form, and paying for the tool |
The link approach is the most popular and the least reliable. A pasted link depends on the responder setting sharing permissions correctly on a file in an account you have no control over. A month later the file has been moved, renamed, or had its permissions tightened, and the record on your side is a URL that returns an access request. If the file matters, a link is not a copy of it.
Collecting by email afterwards works and is honest about being two steps. The cost is that the file and the form response live in different places, which someone has to reconcile by hand every time. That is tolerable at a few submissions a week and unmanageable at fifty.
The third party route is the one most search results push, and it is a genuine option. The thing to check before adopting it is where the uploaded files are stored, who owns them, how long they are kept, and what happens to them if the subscription lapses. Those questions have answers, and the answers should be written down before the form goes out rather than after.
If you keep the upload question, configure it properly
For an audience that is already signed in, the file upload question is a good feature and it is worth spending five minutes on the three controls Google provides for it.
You can specify which file types responders can upload. Use this. An intake that expects a PDF and receives a photograph of a screen, a spreadsheet and a compressed archive of nine files is a reconciliation job that could have been prevented by a setting. Restricting the types also gives the responder a useful error at the moment they can still fix it, rather than a message from you three days later.
You can set the maximum number of files a responder can upload. Match this to what the process genuinely needs. Allowing ten files when the answer should be one invites people to attach everything they have and leave the sorting to whoever opens the folder.
You can choose the maximum file size responders can upload. Setting this too low produces failed submissions from people photographing documents on a modern phone, where individual images are larger than most people expect. Setting it too high fills the owner's Drive with material nobody will read again.
Alongside those three, write down two decisions that the form cannot make for you. Who owns the Drive folder in twelve months, given that it belongs to the account that created the form. And how long the files are kept, since an intake folder with no retention rule becomes an archive of other people's identity documents and bank details by accident rather than by decision.
That last point deserves its own line. An upload field turns a form into a store of documents you are now responsible for. The question of whether responders have to sign in is a usability question. The question of what happens to the files afterwards is a different one, and it is the one that matters more six months later.
The half of the problem that is not about uploading
Assume the upload is solved. Files arrive, from anybody, without an account. What then?
The files are in a folder. The responses are in a form, or a spreadsheet, or both. Matching a document to the submission it belongs to is manual work performed with filenames, and filenames are whatever the responder typed. Two people called their file scan.pdf. A third attached the wrong version and sent the right one the next day, in an email that is now separated from everything else. Somebody has to know whether the document that arrived is the one that was asked for, and whether anyone has looked at it yet.
That work does not appear in any comparison of upload features, and it is where the hours actually go. A file attached to a response, with an owner and a status on the response itself, removes it. A file in a folder next to a spreadsheet does not, no matter how the upload was collected. It is worth seeing what intake looks like when attachments stay with the response before choosing a workaround purely on whether it avoids a login screen, and worth checking how much each approach costs when more than one person is handling the queue.
Deciding rather than defaulting
The decision is narrower than it looks. Ask who fills in the form. If the answer is colleagues, students, or anyone already inside a Google organisation, keep the file upload question and stop worrying about the sign in, because it costs those people nothing.
If the answer is the general public, customers, applicants or suppliers, then a sign in wall in front of an attachment will cost submissions, and the only question left is which of the four alternatives you can live with. Pick on the basis of where the files end up and who has to reconcile them later, not on which one takes least time to configure this afternoon.
What to change first
Open your form's responder link in a private window and find out which setting is actually producing the login prompt, since it is often Limit to 1 response or verified email collection rather than the upload field. If the upload is genuinely the cause and the audience is public, move that form to a tool where a file arrives attached to the response it belongs to, which is what Halict does.
Q1. Is there any setting that allows Google Forms file uploads without signing in?
No. Google's documentation for the file upload question states that responders need to sign in to a Google Account in order to answer it, and no form setting overrides that. Avoiding the sign in means collecting the file some other way, either through a different tool or as a separate step after submission.
Q2. Why is my Google Form asking for a login when it has no file upload question?
Other settings produce the same prompt. Limit to 1 response requires users to sign in to their Google Account to access and fill out the form. Collect email addresses set to Verified takes the address from the signed in account. Publishing the form to a specific domain or audience does the same thing by design.
Q3. Where do files uploaded through a Google Form actually go?
Into a new folder on Google Drive belonging to the form owner. That means they sit under one person's account, so it is worth checking who that account belongs to and what happens when that person changes role, particularly for a form that will collect documents for years.
Q4. Can a file upload question be used on a form kept in a shared drive?
No. Google lists two conditions where the question type cannot be used at all: when the form is stored in a shared drive, and when an administrator turns on Data Loss Prevention. A form that needs uploads has to live in an individual Drive, which is worth knowing before the form is built.
Q5. Is asking people to paste a link to their file a good alternative?
It works and it is free, but it is not equivalent. The file stays in the responder's own storage under permissions you do not control, so links can break, be revoked or point at a file that has since been changed. If the document needs to be retained as a record, collect a copy rather than a reference to one.