How to make a Google Form mobile-friendly

Last updated September 2026 · ~10 minute read

Short answer: there is nothing to switch on. A Google Form already reshapes itself to the width of the screen it opens on, and Google publishes no mobile-specific design control at all — no column widths, no breakpoints, no separate mobile layout, no phone preview. So a form that is miserable to fill in on a phone is miserable because of the questions in it, not because of a setting you missed. Everything below is editorial: which question types hurt on a small screen, and how to check honestly.

Form+ edits your real Google Forms on your own Google account — question types, sections, descriptions and theme, without opening a laptop. Get Form+ free on the App Store.

That makes this a shorter page than the ones offering a mobile mode. There is no mobile mode. What there is: four things that reliably go wrong on a phone, and a test that actually finds them.

What Google publishes about mobile, and what it does not

Worth establishing before anything else, because a lot of advice on this subject assumes a setting that does not exist. Here is what Google's own documentation says on the matter:

• Edit your form documents sections, shuffled question order, shuffled answer choices and the autosave toggle. Nothing about phones, screen widths or layout.
• Change how your form looks documents the theme: header image, theme colour, background colour and the font style for headers, questions and text. No dimensions for any of it, and no mention of small screens.
• Publish & share your form with responders documents getting the link — “At the top right, click Preview and then Copy responder link” — and says nothing about how the form renders anywhere.
• The Forms API exposes a form as info, settings, items, responderUri and a handful of identifiers. Its FormSettings object carries exactly two fields, for quizzes and email collection. There is no layout field, because there is no layout to configure.

The absence is the finding. Google is not merely quiet about mobile design in Forms — there is no column setting, no breakpoint and no mobile preview to be quiet about. The single mobile-specific sentence I could find anywhere in the help centre is in the iPhone & iPad version of “How to use Google Forms”, and it is about building a form in a phone browser rather than filling one in: “Date and time picker is not currently supported for iPhone and iPad.”

There is one documented width control, and it is narrow: an image in a form has a width in pixels, and the API says “When the media is displayed, it is scaled to the smaller of this value or the width of the displayed form.” That is the closest Google comes to acknowledging in writing that a form's width varies — and the behaviour it describes is automatic, so there is still nothing to set.

What actually goes wrong on a phone

Since the container adapts and the content does not, every real problem is a content problem. Four of them account for almost everything.

1. Grids

A grid is a table: rows down the side, options across the top. On a laptop seven columns look balanced. On a phone all seven still have to fit across the screen at once, so the grid has to be dragged sideways — and while the respondent is reaching for a far column, the row label they are answering for can slide out of view. They answer from the wrong row, and neither of you ever finds out.

Nothing in Google Forms narrows a grid, so the only lever is the number of columns. Keep it small, or split one wide grid into several ordinary questions, which costs vertical space — the cheap kind — instead of horizontal space, which is the kind a phone has none of. The full mechanics are in add a multiple choice grid; if you are rating one thing on one scale, a linear scale is the same question without the table.

2. Long option lists

A list of thirty countries is a scroll on a laptop and a chore on a phone, where every option is a tap target competing with its neighbours for a thumb. A drop-down collapses the list to one line, though the choosing still happens inside a scrollable list. The better move is upstream: cut options nobody picks, put a narrowing question first, or let the long tail fall into an “Other” field.

3. Anything that has to be typed

This is the big one, and it is not about layout at all. Typing on a phone is slow, error-prone, and happens under a keyboard that eats half the screen — so every free-text question you can turn into a tap is a question more people will finish. A paragraph question asking why someone chose you is three sentences on a keyboard and a shrug on a phone. Multiple choice plus one optional paragraph at the end gets you most of the same information and loses far fewer people. Where you genuinely need typed input, response validation at least catches the typos the small keyboard causes.

4. Long question titles

A prompt that fits on one line at desktop width can wrap to four on a phone, and a screen full of wrapped prompts reads as work before anyone has answered anything. Keep the prompt to the question and put the explanation in the question description, so the prompt stays one line and the detail sits under it for whoever wants it.

Sections: a shorter scroll, more taps

Splitting a long form into sections is the most common mobile advice, and it is a trade rather than a free win. Each section is a page, so any one screen scrolls less — and every boundary adds a Next tap and a page load. Four questions across four sections is worse on a phone than four questions on one screen; twenty on one screen is worse than four sections of five. The mechanics, and where the boundaries belong, are in Google Forms multiple pages.

The obvious companion is the progress bar, on the grounds that a respondent who can see the end keeps going. Turn it on by all means, but do not promise anyone anything about it: Google has never published what the bar measures, which matters most on exactly the sectioned and branched forms where you would most want to rely on it.

Images and the header

A header image is a banner, and a banner is cropped to fit the shape of the space it is given. A narrow screen gives it a different shape from a wide one, so the part that survives on a phone need not be the part you framed on a laptop: an edge gets trimmed, or text inside the image shrinks past reading. Google documents the crop handles in the editor and nothing at all about how the banner behaves at other screen widths, so treat that as an observation to check rather than a rule to plan around.

Google publishes no recommended dimensions for a header image — not for phones, not for anything — which add a header image to Google Forms covers in full, including what to do instead of inventing a number. The practical version: keep anything that matters in the middle, and never put words you need read into the banner. Images inside questions behave better, since they are scaled down to the form's width automatically — but fine detail scaled down is still fine detail.

File upload asks a phone user to sign in

This one surprises people, and it is documented rather than inferred. Of file upload questions, Google states: “To answer this question, responders need to sign in to a Google Account.” (Add file upload questions.)

On a laptop that is often a non-event, because the person is already signed in. On a phone it is a wall in the middle of your form, possibly on an account that is not the one they use for you — and then the upload itself, frequently over mobile data. If it is worth it, ask last, say in the question description that a Google sign-in is required, and read the file upload limits first, because the storage bill is yours.

Test it on an actual phone

This is the part that is usually skipped and the only step that finds anything. The editor's Preview opens the real responder page — but in your browser, at your window's width, while you are signed in as the owner. It cannot show you a thumb missing a radio button, a grid dragged sideways, or the sign-in wall a signed-out respondent hits — the same gap testing a Google Form before sending it is about, on a wider front. Do this instead:

1. Copy the responder link. In the editor, Preview and then Copy responder link. That link, not the long editing URL, is what a respondent opens.
2. Open it on a phone, in a browser. Message the link to yourself and open it in Safari or Chrome. Narrowing a desktop window is a rehearsal; it has the wrong text size, the wrong tap targets and no keyboard covering the bottom half.
3. Sign out, or use a private window. Signed in as the owner you may open a form a stranger cannot, and you will never meet the sign-in prompt a file upload question raises.
4. Fill the whole thing in and submit it. Every question, with your thumb, grids and long lists included. Reading a form is not completing one, and the questions that hurt only hurt when you answer them.
5. Change the questions, not the settings. Whatever annoyed you is a question to edit: split the grid, shorten the list, swap typing for tapping, move detail into the description. There is no layout control to adjust instead — that is the whole point of this page.

Then delete the test response, so your data starts clean: clear Google Form responses.

The checklist

• No grid wider than a handful of columns — and none at all if you can ask it another way.
• No option list long enough to need scrolling to reach its end.
• Every free-text question justified. If tapping could answer it, tapping should.
• Question prompts short; the explanation in the description.
• Sections used to break up a genuinely long form, not to break up a short one.
• Nothing essential written inside the header image.
• File upload asked for last, if at all, with the Google sign-in flagged in the description.
• The responder link opened, signed out, on a real phone, and submitted.

Where Form+ fits

Every change above is an edit to the form, and Form+ is a native iPhone and iPad editor and response client for your real Google Forms on your own Google account — so the fixes can happen on the device that found them. The question type picker turns a grid into ordinary questions or a paragraph into multiple choice, and sections, descriptions and the theme are editable from the phone you just tested on. Its Form Audit tool, a PRO feature, also flags a question title over 200 characters and suggests moving the detail into the description — the long-title problem above.

What it cannot do: change what a respondent sees. They open Google's responder page in their own browser, and no app of ours is involved in that. Form+ improves the form; the form is what improves the phone experience.

Frequently asked questions

Is there a mobile layout setting in Google Forms?

No, and there is nothing partial either. The help pages for editing a form, changing its look and publishing it document no column widths, no breakpoints, no separate mobile layout and no phone preview, and the Forms API exposes no layout field on the form or its settings. The form adapts to the screen on its own; what you can influence is the content of the questions.

Why does a grid question scroll sideways on a phone?

Because a grid is a table, and every column has to fit across the screen at once. Past a handful of columns it has to be dragged sideways, and the row label can slide out of view while the respondent reaches for a far column. Fewer columns, or separate questions.

What size should a header image be for a phone?

Google does not say — it publishes no header image dimensions anywhere, for any screen size. Since the banner is cropped to whatever shape the screen gives it, keep what matters in the middle and keep words you need read out of the image.

Does the editor preview show me what a phone sees?

Not really. Preview opens the real responder page, which is the right page, but it opens it in your browser, at your window's width, while you are signed in as the owner. It cannot show you a thumb missing a radio button, a grid dragged sideways, or the sign-in wall a signed-out respondent meets. Open the responder link on an actual phone instead, signed out, and fill it in.