Google Forms required vs optional: what each one enforces

Last updated September 2026 · ~10 minute read

Short answer: a question is optional until you turn on Required, and Required blocks the respondent from leaving the page that question sits on — not only from pressing Submit. One switch does not buy one behaviour, though: what it enforces on a grid, a checkbox question and a file upload are three different things, and the two states leave two different shapes behind in your data.

For the steps, required questions in Google Forms covers the switch itself. This page is the part underneath: when the check fires, why it is not the same check on every question type, what an optional question leaves in a response, and what Google does and does not promise about a required question inside a section nobody visits.

One switch, three vocabularies, no stated default

Required is a property of one question, and Google names it three times. In the editor it is a button in the question's footer row — the page that spells that row out is Google's screen reader guide, where the action buttons “let you: Duplicate the question, Delete the question, Make the question required.” Elsewhere in the help centre it is one sentence: “To prevent people from not answering, turn on Required.”

In Apps Script it is setRequired(enabled), described identically on every question class that has it — “Sets whether the respondent must answer the question.” Google's own sample on the Form class page is a one-liner: item.setRequired(true);, commented “Sets the question as required.”

In the REST API it is a boolean on the Question object, worded most precisely of the three: “Whether the question must be answered in order for a respondent to submit their response.” The v1 discovery document carries the same sentence — and no default value, in either reference. Every new question behaves as optional; Google never writes that down. Nor does validation appear anywhere in that discovery document: required is exposed to developers, response validation is not.

When the check actually fires

Most people assume Required is a submit-time check. On a single-page form it looks that way; with sections it is not, and Google documents both moments on one page — Fix common errors while you respond to a Google Form.

At submit: “ensure you've answered all required questions. Check for any fields highlighted in red with the message ‘This is a required question,’ which indicate that they're mandatory.” That is the published error string, and the reason a Submit button that appears to do nothing usually is doing something.

At the page boundary: “If you can't click the ‘Next’ button to move to the next question or section, it means some required fields are incomplete or some answer validation error is not resolved.” Each section is validated as the respondent tries to leave it. The rules page says the same from the other side — if they don't answer, “they get an error message and can't continue.”

That fact carries the rest of this page: Required is enforced at the moment you try to leave the page it lives on.

The same switch, four different enforcements

Short answer, paragraph, date and time: not empty

The plain case everybody generalises from: the field must contain something. It need not contain anything sensible — a required short-answer question accepts a single character.

Checkboxes: required and “select exactly” are two gates

Required on a Checkboxes question means at least one box. The count rules are a different control entirely — Google's rules page lists three: Select at least, “Set a minimum number of boxes that can be checked”; Select at most, the same for a maximum; and Select exactly, “Specify the number of boxes that must be checked.”

So the two stack: a question can be optional yet reject two ticks when the rule says three, or required yet accept one tick when you meant three. “Pick your top three, always” needs both switches on. More in add a checkbox question.

Grids: the switch is per row, and it has its own error

A grid is where “required” stops being one thing. The editor control is not the ordinary toggle — Google's wording is “To make sure responders choose an option from each column, turn on ‘Require a response in each row.’ If they don't, they get an error message and can't continue.” (That sentence says column where it means row; the respondent-facing page gets it right.)

That error has a published string too: “This question requires one response per row,” which Google explains as “each row must have at least one multiple choice or checkbox selected.” Not answer this question, but answer every row of it.

The two APIs model that differently. Apps Script gives a grid one setRequired(enabled), worded exactly as on a short-answer question. The REST API does not: its Grid object holds only columns and shuffleQuestions and has no required field at all. A grid there is a QuestionGroupItem wrapping a list of Question objects — one per row — and each of those carries its own required boolean. One switch in the editor, one boolean in Apps Script, N flags over REST, and no page describing how the first maps onto the last.

File upload: required changes who can answer at all

The outlier. Google's respondent page states that “in some forms, owners may require you to upload files. To complete the upload in response to a question, you need to sign in to your Google Account.” Making a file upload question required therefore does what no other Required switch does: it turns the form into one anonymous respondents cannot finish — see add a file upload question. And neither API can set this one: the REST reference says flatly that “the API currently does not support creating file upload questions,” and Apps Script exposes a FILE_UPLOAD item type with no item class to cast it to.

The required field you never created

Turn on email collection and, in Google's words, “when someone takes your survey, they will be required to enter their email address before they submit the form.” It is not in your question list and has no Required switch — only the collection setting itself.

What “optional” actually leaves behind

This is the half nobody writes down, and the half that breaks scripts. An unanswered optional question does not produce one consistent thing — it produces two, and which one depends on the question type.

Apps Script's FormResponse documents the split exactly: “If the form response does not contain a response for a given TextItem, DateItem, TimeItem, or ParagraphTextItem, the ItemResponse returned for that item will have an empty string as the response. If the form response omits a response for any other item type, this method excludes that item from its returned array.”

Four question types come back present-but-blank. Every other type — multiple choice, checkboxes, dropdown, scale, rating, grids, file upload — is simply not in the array. Two consequences follow, both the kind of bug that survives testing:

• A blank and a skip are indistinguishable on those four types. An empty string means “they left it blank” and “this was never on their path” identically.
• Never read answers by position. Index 3 is not question 4 for a respondent who skipped a dropdown. Match on the item, not the offset.

The REST side is consistent and blunter: a FormResponse returns answers as a “map (key: string, value: object (Answer))” — “the actual answers to the questions, keyed by questionId.” A question with no answer contributes no key. There is no placeholder at all.

Quizzes get one documented exception: getGradableItemResponses() differs on purpose, “to allow for grading a missing answer” — it “still returns an ItemResponse if the corresponding Item can be graded … even if there isn't an actual response.” Google's own API assumes, in writing, that a submitted response can contain a missing answer.

A required question in a section nobody visits

Show questions based on answers — the whole of Google's branching documentation — runs to a handful of sentences. It explains “Go to section based on answer,” notes that the option “is only available for Multiple choice and Dropdown question types,” and stops. The word required never appears on it, and neither API reference describes the interaction.

What you can assemble from what Google does publish: the enforcement moment is the page boundary, and Next is blocked by incomplete required fields on the section you are trying to leave. A section you are routed past is never a section you try to leave, so there is no moment at which its required questions could fire. The response format agrees — a question you were never shown contributes no key, exactly like an optional one you chose to skip.

That is a reading, not a promise, and we are labelling it as one. Before you build a form whose data integrity depends on it, copy the form, put a required question inside a branch, route yourself around it, submit, and look at what arrives. The caution runs both ways: a question that is required and unreachable is not a safety net, it is dead weight.

Where Google is silent, precisely: the red asterisk and the line “* Indicates required question” ship on every published form but appear on no help page; nothing states the default value of the required flag; nothing describes how one grid switch maps to the per-row flags in the API; and nothing anywhere covers required questions inside a skipped section.

Required vs optional, side by side

Auditing this from an iPhone or iPad

Forms+ is a native editor for your real Google Forms on your own Google account, so everything here writes through to the live form behind its real link.

The per-question switch is labelled Required, in the same footer row Google describes; on a Multiple choice grid or Checkbox grid that row reads Require a response in each row, matching Google's own name for it. Neither sits behind an upgrade. Bulk Edit… in the editor's tools menu lets you select many questions and apply Mark required or Mark optional in one pass. Audit form (pre-publish)… is a PRO feature: it raises Key contact field is optional on an email, name or phone question you left optional, with a one-tap Make required fix. It is not the only PRO row in the app — this is not a full list of what is gated.

Frequently asked questions

Are required questions enforced only when someone presses Submit?

No. Google's respondent troubleshooting page documents both moments. A blocked Submit means an unanswered required question somewhere in the form, flagged in red with the message “This is a required question.” But it also states that if you cannot click Next to move to the next section, “some required fields are incomplete or some answer validation error is not resolved.” On a form split into sections, the check fires at every page boundary you cross, not once at the end.

What happens to a required question in a section the respondent skips?

Google does not state it anywhere: the branching help page never mentions required questions, and neither API reference describes the interaction. What Google does document is that the block fires when you try to leave the page a required question sits on — and a section a respondent is routed past has no such moment. Treat that as a reasonable reading rather than a promise, and test your own branch before you depend on it.

Does an optional question leave a blank or nothing at all in a Google Forms response?

Both, depending on the question type. Apps Script documents the split precisely: for a text, paragraph, date or time question the response object comes back with an empty string, but for every other item type an unanswered question is excluded from the returned array altogether. So you cannot tell a deliberate blank from a skipped question on the four free-entry types, and you must never read answers by position.