How to test a Google Form before sending it

Last updated September 2026 · ~10 minute read

Short answer: Preview is not a test. Google documents it in one sentence — “At any time, you can preview your form to see what the changes look like” — and nowhere states whether a submission from that window is recorded, or whether branching, validation and required questions behave there as they do for a responder. The only test that settles anything is a real submission through the responder link, which leaves a real test response in your data. Google is blunt about the cleanup: “If you delete any responses in a form, it can't be undone.”

So the question is not whether to test, but which of the two things called “testing” you are doing — and what the honest one costs.

What Google publishes about Preview

Less than you would expect, and worth seeing whole before you build a process on it. Across the help centre, Preview appears in four places:

• Create your first form has a section headed “Preview it yourself”: “At any time, you can preview your form to see what the changes look like.” Then the mechanics — “At the top right, click Preview. The preview opens in a new window.” and “To edit the form, click Edit or go back to your editing window.”
• The same page repeats it as an editing tip: “To preview your changes at any time, at the top right, click Preview.”
• Publish & share your form with responders uses Preview as the route to the link itself: “At the top right, click Preview and then Copy responder link.”
• The screen reader page gives a shortcut: “Preview the form: Press Ctrl + Shift + p.”

Read those together and Preview's documented job is narrow and consistent: it shows you what the form looks like. Every sentence Google writes about it is about appearance, or about navigating between two windows.

What Preview does not tell you — and Google never says

This is the centre of the page, so here it is without hedging. There is no Google page stating:

• whether a submission from the preview window is recorded as a response;
• whether conditional branching follows the same paths in preview as it does for a responder;
• whether response validation and required questions are enforced identically there.

The silence is the finding, not a gap for us to fill with a guess. Google describes Preview as a way to look at your form; it never calls it a test environment, a sandbox or a dry run, and never draws a line between a preview submission and a real one in either direction.

What follows is practical. Without a documented guarantee that preview behaves like production, a clean run through Preview is not evidence that your form works — only that it looks right, which is useful and much smaller. Treat Preview as proofreading: wording, order, images, theme, typos. Nothing downstream of the Submit button belongs to it.

Publishing now sits between you and any real test

There is a second reason Preview flatters you, and this one is documented. Forms are published explicitly now. Google's Learning Center states it flatly — “Before responders can access your form, you need to publish it” — and the help centre adds the failure mode: “If the form is unpublished, responders with the link can't access it.” The Forms API puts it from the other side, where unpublishing “makes it unavailable and automatically stops it from accepting responses.”

Preview works for the owner regardless. An unpublished form therefore looks completely testable to you and is a dead link for everybody else — a failure that hits every recipient at once, silently. Publish first, test second.

A real test means a real response, and that has a price

A submission through the responder link is a response in every sense Google's product recognises:

• It counts. Your response count reads 1 when it should read 0, and every percentage in the summary is computed against a population including you.
• It lands in the linked spreadsheet as a timestamped row, beside the real ones.
• It triggers whatever the form triggers — notification emails, receipts, and any automation watching for submissions.
• Removing it is irreversible. Google's warning is a single sentence: “If you delete any responses in a form, it can't be undone.”

And removing it in the form is half the job. Deleting a response does not remove the copy already written to a linked spreadsheet — separate stores — and if you meant to script the cleanup, the Forms REST API has no delete method for responses at all. Full mechanics, including the Apps Script route that does work: how to clear Google Form responses.

None of that argues against testing. It argues for testing once, deliberately, with a cleanup already planned — not six casual submissions to unpick from two places.

The checklist worth actually running

Seven steps, in this order: cheap checks first, the one irreversible act late, cleanup as a step rather than an afterthought.

1. Publish, then copy the responder link. In the editor, Preview → Copy responder link. That link, not the long editing URL, is the thing under test.
2. Open it as someone who is not you. A private window, or a second Google account — the step that finds the access problems, and the one everyone skips.
3. Walk every branch path. Answer the branching question once per possible destination, not once. Google's troubleshooting page describes the symptom you are checking for: “a form returns to the same question or takes you back to a previous one when you click ‘Next.’ This behavior is often intentional, as form owners can set up forms to loop back to earlier sections based on your answers.” Intentional when you meant it; an inescapable loop when you did not. Conditional logic has the mechanics.
4. Break it on purpose. Leave every required question blank and press Next — you should meet “This is a required question.” Then type something invalid into every validated field. Google notes that a blocked Next button “means some required fields are incomplete or some answer validation error is not resolved” — see that from the respondent's side, in the wording you chose. A rule you never tripped is configured, not tested.
5. Submit, and read what comes back. The confirmation message is the last thing a respondent sees from you, and it stays at the placeholder “Your response has been recorded” until you change it. Does it tell a stranger what happens next?
6. Test the close behaviour. Turn Accepting responses off, reload the responder link, and read what a late arrival gets — Google's error page lists it as “Form is no longer accepting responses.” Then turn it back on. Stopping responses covers the scheduling.
7. Open the same link on a real phone and fill it in with your thumb. Grids, long option lists and typing are where a desktop-shaped form falls apart, and narrowing a browser window reproduces none of it. Making a form mobile-friendly covers what to change when it does.

The trap: testing as the owner hides the owner's problems

A form behaves differently for you than for a stranger, and that difference is where forms break. You are signed in, you own the file, and your browser already carries the session three separate settings will demand from everyone else. All three are documented:

Note the asymmetry: Google states the requirement bluntly for the first two and only implies it for Verified. Either way, none of the three announces itself to the owner, because the owner is already signed in. Add audience restrictions on top — owners “can restrict the access to a domain, trusted audience, or group of users” — and you can test a form flawlessly that half your recipients cannot open.

Be specific: a private window tests the signed-out stranger, a second account tests the wrong account, and those fail differently.

Testing from the phone the form will be read on

Every path above assumes the desktop web editor. Forms+ is a native iPhone and iPad client for your real Google Forms on your own Google account, so the loop can run on the device most respondents will use. Its Preview tab loads the live responder page inside the app, and is honest about what that means: on a real form, submitting from it submits. The one place it intercepts the Submit tap is its sample form, where it says so outright — “In your own form, tapping Submit would send the response to Google Forms.”

What the app adds comes before the test. Audit form (pre-publish) — a PRO feature, in the editor's tools — scans for the defects a walkthrough is bad at spotting, because they are absences rather than errors: a contact field left optional (“Mark it required so you don't collect blank responses”), a text question asking for an email, phone, number, URL or postcode with no validation, a choice question with fewer than two options, a quiz question carrying no points, duplicate titles, and a prompt over 200 characters. Each carries a one-tap fix where one exists — a cheaper first pass than a submission, and it costs you no row in your spreadsheet.

Before you send the link: clear the test data

• Delete the test response in the form. Responses → Individual → Delete → YES for one; Responses → Summary → More → Delete all responses → OK for the lot. Both permanent.
• Delete the matching row in the linked spreadsheet. It is a separate file and it does not follow. Skip this and every later export carries your test forever.
• Check the uploads folder if you tested a file upload question. Google does not publish what deleting a response does to the Drive file it pointed at — look rather than assume.
• Re-check the count. Zero before you send the link, or you missed a submission.
• Confirm the form is published and accepting responses — step six turned that switch off.

Then send it. A form that was published, opened by a second account, branched through, broken on purpose, submitted once and cleaned up is in a different category from one that looked fine in Preview — and the gap between them is about a quarter of an hour.

Frequently asked questions

Does submitting a Google Form in Preview count as a response?

Google does not publish an answer. Its documentation describes Preview in one sentence — “At any time, you can preview your form to see what the changes look like” — and no Google page states whether a submission made from that window is recorded, or whether branching, validation and required questions behave there exactly as they do for a responder. Because the documentation is silent, do not treat a preview run as evidence either way. Test with the responder link.

Why can my testers not open the form I just previewed?

Most likely because the form is not published: “if the form is unpublished, responders with the link can't access it.” Preview works for the owner regardless, so a form can look perfectly testable to you and be unreachable for everyone else.

Can I delete a test response after submitting it?

Yes, but not reversibly and not everywhere. “If you delete any responses in a form, it can't be undone.” Deleting in the form does not remove the copy already written to a linked spreadsheet, and the Forms REST API has no delete method for responses at all — see clearing Google Form responses.

Why does Google Forms ask my testers to sign in?

Three settings are documented as needing a Google account. Limit to 1 response: “To access and fill out the form, users must sign in to their Google Account.” A file upload question: “To answer this question, responders need to sign in to a Google Account.” And Collect email addresses → Verified, which the Forms API describes as collecting addresses “based on the account of the signed-in user.”