Google Forms has conditional logic, and it works differently from almost every other form tool. Knowing that difference before building the form saves a rebuild, because the feature is organised around sections rather than around individual questions, and a form written as one long list cannot be branched without being restructured first.
This covers what the feature is called, how to set it up, which question types can drive a branch, the limits worth planning around, and how to check every path before the form goes out. It also covers what the workarounds are for the cases Google Forms cannot handle, because there are several and most of them are not obvious.
The feature is called "Go to section based on answer"
There is no conditional logic panel and no rule builder. Instead, two separate mechanisms combine.
The first is the section. A section is a page break with a heading, added with Add section, and Google's documentation puts the ceiling at 75 sections in one form and 300 pieces of content overall, counting questions, descriptions, images and videos together. At the bottom of every section there is a destination setting that says where the respondent goes next.
The second is per answer routing on a single question. Open the question, use the More menu, and choose Go to section based on answer. Each option in the question then gets its own destination. Google's documentation also notes that one of the available destinations is Submit form, which ends the form immediately. That is the setting to use for respondents who do not qualify, and it is the most valuable thing in the whole feature.
The consequence of both mechanisms operating on sections is that the branch unit is a page, not a field. A single question cannot be hidden. To make one question conditional in Google Forms, that question has to live in a section of its own.
Setting it up
Build in this order. Doing it the other way round means setting destinations twice.
Write the sections first. Decide the paths before writing any questions, then create one section per path plus a shared section at the start and, usually, a shared section at the end. Name them in a way that makes the branch obvious in the editor, because the destination dropdown shows section names and nothing else.
Put the deciding question in the first section. It has to be a question type that supports routing, and it has to come before anything that takes effort to answer. A respondent who fills in six fields and is then routed to a rejection has wasted their time and yours.
Set the per answer routing. On the deciding question, open More, choose Go to section based on answer, and set a destination for every option including any you expect nobody to pick. An option left on the default sends that respondent to whatever section physically follows, which is rarely what was intended.
Set the fall through on every section. At the bottom of each branch section, set where it goes next. Left alone it continues to the following section, which means the first branch flows straight into the second branch's questions. This single default is responsible for most broken Google Forms.
Send converging paths to the same closing section. If every path ends with the same two questions, make those a final section and route each branch to it rather than duplicating the questions.
Which question types can drive a branch
This is where Google's own documentation is not consistent, and it is worth knowing before designing around it.
The page on showing questions based on answers states that Go to section based on answer is available only for Multiple choice and Dropdown question types. The reference page on question types says the same of Multiple choice and Dropdown, and also lists Checkboxes as a question type whose answers can send a respondent to a certain section.
The practical approach is to check the form itself: open the question, open the More menu, and see whether the option appears. Design the branch around a Multiple choice or Dropdown question when there is a choice, because that is the combination documented in both places.
What definitively cannot drive a branch is everything else. Short answer and Paragraph cannot. Linear scale, which Google documents as starting at zero or one and ending on a whole number from 2 to 10, cannot. Rating, offered as stars, hearts or thumbs up on a scale of 3 to 10, cannot. Date, Time, File upload and both grid types cannot. If the branch depends on a number or a date, Google Forms will not do it directly.
The mirror question workaround
The usual workaround is to ask the same thing twice in a different shape. Instead of branching on a number, offer ranges as Multiple choice options: under 10, 10 to 50, over 50. Instead of branching on a date, offer named periods. The respondent answers one extra question, the branch works, and the exact value can still be collected as a Short answer inside the branch that needs it.
Three limits to plan around
Sections and items. 75 sections and 300 items sound generous until a form has four paths each with a dozen questions. Counting before building is quicker than discovering the ceiling halfway through.
File upload changes who can answer. Google documents that a File upload question requires the responder to sign in to a Google Account, and that the question type is unavailable if the form is stored in a shared drive or if the administrator has turned on Data Loss Prevention. Uploaded files land in a new folder on Drive. For an internal form this costs nothing. For public intake it removes everyone who is not signed in, which is a much larger group than it appears from inside a Google account.
Shuffle and branching do not mix. Shuffle question order is a form level setting under Presentation, and Google's own note is explicit that questions should not be shuffled when they need to appear in a specific order. Branching depends entirely on order, so leave shuffle off on any branched form. The same page documents that shuffling happens only once per email address, which is a separate reason it behaves unpredictably on a public form.
Data validation is a different feature, and it is often what people wanted
Searches for conditional logic in Google Forms frequently turn out to be about constraining an answer rather than about hiding a question, and Google keeps those in two different places.
Data validation sits on the question itself. Google documents Short answer and Paragraph as accepting rules such as a maximum character count, and the grid question types as accepting rules such as limiting one choice per column. These rules reject an answer at the point it is typed, with a message the respondent sees immediately. Nothing is hidden and no section is skipped.
That is the right tool for three common cases. An email address that has to look like an email address. A number that has to fall inside a range. A reference code that has to match a pattern. Trying to express any of those as a branch produces a form with a section whose only purpose is to tell somebody they typed the wrong thing, which is worse for the respondent and worse for the export.
The dividing line is simple. If the goal is to stop a bad answer, use validation on the question. If the goal is to avoid asking a question at all, use a section and route past it. Forms that mix the two intentionally, validating inside each branch, tend to be both shorter and cleaner than forms that lean on one mechanism for everything.
Testing a branched form
A branched Google Form needs walking, not reading. The editor's preview does not show the destinations, so the only way to see the paths is to take them.
List every path first, including the ones that end at Submit form. Then open the live form in a private window and complete each path as a real submission, checking three things each time: that the sections appear in the intended order, that no required question is sitting in a section the path was supposed to skip, and that the response landing in the responses tab matches the path taken.
One setting worth knowing about during testing: Google documents that draft responses are autosaved for 30 days after a respondent's last edit by default, and that autosave can be turned off under Presentation. Google lists forms embedded in websites, forms used for repeated data entry, and forms used on shared devices as the cases where turning it off makes sense. On a shared device an autosaved draft from the previous person is visible to the next one, which matters more on a registration form than the branching does.
Use Duplicate section when a path needs a near copy of another, and Move section with care, because moving a section changes the physical order and therefore changes every fall through destination that was left on its default.
Where a branched Google Form starts to hurt
The branching itself holds up well. What tends to run out is everything after the response arrives.
A branched form produces a sparse spreadsheet: every question in every path is a column, and each row only fills the columns on its own path. Totals across the whole sheet stop meaning anything, because the denominator differs per column. Recording which path a respondent took as an actual answer rather than leaving it implied makes the export readable, and costs one hidden question.
The larger gap is that Google Forms has no concept of a response belonging to anybody. There is no owner, no status and no record of what was sent back. Teams fill that in by hand: a linked sheet with columns for who is handling it and what stage it has reached, updated manually, with the replies living in individual sent folders. That works until two people reply to the same application on the same morning, or until a respondent follows up about a message nobody can find.
If the form has reached the point where branching is needed, it has usually also reached the point where that manual layer costs real time. Tools that keep an owner and a status on the response itself remove it, along with the export cycle, and what each plan includes is worth comparing against the hours currently going into the sheet.
What to change first
Open the form and check two things: that every option on the deciding question has an explicit destination, and that every section has an explicit next step rather than the default fall through. Those two account for nearly every branch that misroutes. Then, if the responses from those branches are being tracked in a spreadsheet by hand, see the same responses carrying an owner and a status in Halict or any tool built the same way, and compare that against the columns being maintained today.
Q1. Can Google Forms hide a single question instead of a whole section?
No. Branching in Google Forms operates on sections, so a question that needs to be conditional has to be placed in a section of its own. That works, but a form with many individually conditional questions ends up with a section per question, which is harder to read in the editor than a tool with field level conditions.
Q2. Can Google Forms branch on a number or a date?
Not directly. Go to section based on answer is documented as available for Multiple choice and Dropdown questions, and the question type reference also mentions Checkboxes. Linear scale, Rating, Date, Time, Short answer and Paragraph cannot drive a branch. The usual workaround is a Multiple choice question offering ranges, with the exact value collected separately inside the branch.
Q3. Why does my Google Form show the wrong section?
Almost always because a section was left on its default next step. Every section continues to the one physically after it unless told otherwise, so the first branch flows straight into the second branch's questions. Check the destination at the bottom of every section, and check that each option on the deciding question has its own destination.
Q4. How many sections can a Google Form have?
Google documents up to 75 sections, and up to 300 pieces of content in total across questions, descriptions, images and videos. A branched form consumes both faster than a linear one, so it is worth counting the paths before building rather than after.
Q5. Do respondents need a Google account to fill in a branched form?
Not for branching itself. They do need to sign in if the form contains a File upload question, which Google documents as requiring a Google Account, and that question type is also unavailable when the form sits in a shared drive or when Data Loss Prevention is turned on. Collecting verified email addresses or limiting to one response per person has the same effect.