Most guides about Google Forms and your website answer a question you did not ask.

Search for how to replace a Google Form with your own HTML and you get three kinds of answer. Embed the iframe but style the container. Use a service that hides Google's branding. Or the clever one: build your own HTML form and point it at Google's endpoint, so responses still land in your existing spreadsheet.

All three keep Google Forms in the loop. If that is what you want, they work, and I will show you the third one because it is genuinely useful when you need it.

But if you actually want the Google Form gone, replaced by markup you own, here is how that works and what it costs you.

One-line summary: Google Forms does one thing your static site can't, accept a POST; swap that for a form endpoint and you get your markup back, at the cost of owning spam and losing free-unlimited.

Why the iframe is the problem

The embed is an iframe. That means:

  • You cannot restyle it. Your fonts and colours stop at the border.
  • It does not resize with its content, so a long form becomes a scroll area inside your page.
  • It looks like Google on your site, because it is.
  • You inherit its accessibility behaviour and can do nothing about it.

None of that matters for an internal survey or a sports club sign-up sheet. It matters a lot on a business site, where a Google-branded iframe reads as a stopgap someone never got round to replacing.

The clever workaround, and where it breaks

You can POST your own HTML form straight at a Google Form's response endpoint. Open your form, inspect the page, dig the field IDs out of the markup, and build a form whose input names match:

<form action="https://docs.google.com/forms/d/e/YOUR_FORM_ID/formResponse" method="POST">
  <input name="entry.1234567890" type="email" required>
  <textarea name="entry.9876543210" required></textarea>
  <button type="submit">Send</button>
</form>

Enter fullscreen mode Exit fullscreen mode

Responses land in the same spreadsheet. No new service. For a throwaway internal page, this is fine.

The guides that recommend it tend to stop there, so here is the rest.

The field names are opaque and fragile. entry.1234567890 means nothing to the next person reading your template, and it is tied to a form you now have to keep alive in someone's Google Drive.

You cannot read the response. Google does not send CORS headers for this endpoint, so a fetch either fails or you send it with mode: "no-cors" and get an opaque response back. You cannot tell success from failure. Submitting the form natively navigates the user to a Google-branded confirmation page you do not control.

There is no server-side validation you own. Whatever Google's form does with a malformed submission is what happens.

Nothing tells you when it breaks. If the form is deleted, renamed, or its fields change, your site keeps posting into the void and you find out when someone asks why you never replied.

It is a workaround. Treat it as one.

Replacing it properly

A real HTML form needs somewhere to POST. That is the only thing Google Forms was actually providing that a static site cannot do alone.

The markup is ordinary:

<form action="https://api.formpaste.com/submit" method="POST">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">
  <input type="email" name="email" placeholder="Your email" required>
  <textarea name="message" placeholder="Your message" required></textarea>
  <button type="submit">Send</button>
</form>

Enter fullscreen mode Exit fullscreen mode

That is a real form. Your CSS applies. Your validation applies. The field names are the field names. Submissions arrive by email.

I work on Formpaste, which is what that endpoint is, so weigh the recommendation accordingly. Formspree, Web3Forms and Basin do the same job and the rest of this post applies to all of them. What matters is the shape: your markup, someone else's endpoint.

Sending people somewhere after submit

By default the browser posts and shows a response. If you want your own thank-you page, add a redirect field:

<input type="hidden" name="redirect" value="https://yoursite.com/thanks">

Enter fullscreen mode Exit fullscreen mode

Worth knowing that any endpoint accepting a redirect target has to validate it, otherwise it is an open redirect that spammers will find and use to launder links through your domain. Formpaste checks it against the form's allowlisted domains and rejects anything else. If you are evaluating another service, that is a fair thing to ask about.

Keeping the spreadsheet

This is usually the real objection. The Google Form was feeding a Sheet, and something downstream reads that Sheet.

You have two options. Export the existing responses to CSV and keep them as an archive, which costs nothing and takes a minute. Or keep new submissions syncing into a Sheet automatically, which most form backends offer as a paid integration. On Formpaste it is a Pro feature, not a free one, and I would rather say that here than have you find out at the paywall. It appends a timestamped row per submission and adds a column when a new field shows up rather than silently dropping the value.

If the spreadsheet is load-bearing for you, price that in before you migrate.

Spam, which Google was quietly handling

Google Forms is not much of a spam target because the endpoint is obscure and reCAPTCHA is one toggle away. A public form endpoint on your own domain is a different proposition. Once you move, you own this problem.

The usual answer is a CAPTCHA. It works, and it makes every real visitor solve a puzzle to talk to you, which on a contact form is a strange trade.

The alternative is scoring submissions on signals the visitor never sees: a honeypot field bots fill and humans do not, how fast the form was completed, submission rate from one source, disposable-email domains. Anything borderline goes to a review folder instead of being deleted, so a false positive is recoverable rather than a silently lost message.

Whatever you pick, decide it deliberately. A brand-new public endpoint with no spam handling gets found.

When to keep Google Forms

Genuinely, sometimes:

  • Non-technical people need to edit the form. Google Forms has a UI for that. A hand-written HTML form means editing markup and deploying.
  • You need quizzes, branching, or conditional logic. That is a survey tool's job. Rebuilding it in raw HTML is work you do not want.
  • It is a one-off. An event RSVP that runs for three weeks does not need a migration.
  • Budget is zero and volume is high. Google Forms is free and effectively unlimited. Hosted form backends have free tiers with monthly caps. Formpaste's free plan is 250 submissions a month across 3 forms; others differ. If you are collecting thousands of responses and do not care how it looks, Google wins on price.

Rebuild when the form is a permanent part of a site you control the design of, and the people maintaining it are comfortable in a code editor. That is the whole rule.

The migration, start to finish

  1. Export the existing responses from the linked Sheet. Keep the file.
  2. Write the HTML form. Same fields, real names, your markup.
  3. Point it at an endpoint and confirm a test submission arrives.
  4. Style it. This is the part you could not do before.
  5. Add a redirect to your own thank-you page.
  6. Decide on spam handling before you make it public, not after.
  7. Replace the iframe. Leave the old Google Form in place, closed to responses, until you are sure.
  8. If anything downstream read that Sheet, either point it at the archive or set up a sync.

Step 7 is the one people skip. Keep the old form until you have seen real submissions arrive through the new one.

If you are still deciding whether to rebuild at all, I wrote about that trade-off separately: Putting a Google Form on Your Own Website (And When to Rebuild It Instead).