How to embed a Google Form on a website
Last updated September 2026 · ~10 minute read
Short answer: In the Google Forms editor, open the More
menu at the top right and choose Embed HTML, then click Copy and paste the
HTML into your page. That gives you an iframe with a fixed pixel height — which
is why long forms end up with their own scrollbar and short ones leave a gap. The fix is CSS on your side,
and it has a real limit: a cross-origin iframe cannot size itself to its contents.
Getting the code takes about fifteen seconds. Making it not look broken on a phone is the actual job, and it is where almost every guide on this subject quietly promises something that browsers do not allow. This page separates what Google documents from what you have to do yourself, and says plainly which is which.
Step 1 — Get the embed code from Google
Google's help page for publishing and sharing a form has a section headed “Embed a form on a website or blog”. Its steps, verbatim:
- “Open a form in Google Forms.”
- “At the top right, click More menu.”
- “Select Embed HTML.”
- “To copy the HTML that shows, click Copy.”
- “Paste the HTML into your website or blog.”
That is the whole of it. Worth knowing what Google's instructions stop short of: the help page does not print the HTML it hands you, does not document the width and height boxes in that dialog, and does not state any default values for them. So treat the dimensions below as a description of what the dialog produces in practice, not as a documented Google specification — they have changed before and can change again.
One correction worth making, because it circulates widely: Google's page does list questions that block embedding — “File upload question”, “Rating question”, “Image in a question or an option”, “Secured quiz”. That list sits under “Email a form” and is introduced by the sentence “You can't embed a form in an email when it contains:”. It is a limitation of embedding a form inside an email message, not of embedding it on a website. A form with a file upload question embeds on a web page fine.
Step 2 — What the snippet actually looks like
The markup Google generates follows this pattern. Everything except the address is boilerplate — and the string in that address is not your form ID, which is the point most guides get wrong:
<iframe
src="https://docs.google.com/forms/d/e/1FAIpQLSd.../viewform?embedded=true"
width="640"
height="800"
frameborder="0"
marginheight="0"
marginwidth="0">Loading…</iframe>
Do not paste your form ID into that slot. The value after /d/e/ is a
separate published-form token — a long string beginning 1FAIpQLS — and it is not the ID you
see in the editing URL at /forms/d/FORM_ID/edit. They are different strings for the same
form, and substituting one for the other gives you an embed that does not load. Always copy the snippet
Google generates rather than assembling one by hand; we pull the two apart in
form IDs and URLs.
Three things in there matter:
?embedded=true— this is the part that makes it an embed. It strips the Google Forms page furniture so you get the form itself rather than a whole Google page inside your page. Keep it.widthandheight— plain HTML presentation attributes, in pixels. They are the source of every sizing complaint on this page, and any CSS you write beats them.Loading…between the tags — fallback text for browsers that will not render the frame. Harmless; leave it.
Paste it into a raw HTML or custom HTML block. Pasting an iframe into a rich-text editor is the single most common reason an embed shows up as literal text or vanishes entirely — the editor escapes or strips the tag before it ever reaches the page.
Step 3 — Making it responsive (this part is not Google's)
Guidance, not documentation. Google publishes nothing about how its iframe should behave at different screen sizes. Everything in this section is ordinary CSS practice that I am recommending, and you should treat it as such.
The problem is precise: width="640" is wider than a phone, so the embed overflows and drags a
horizontal scrollbar across your layout. Width is the easy half. Wrap the iframe and let CSS take over:
<div class="form-embed">
<iframe
src="https://docs.google.com/forms/d/e/1FAIpQLSd.../viewform?embedded=true"
width="640"
height="800"
frameborder="0"
marginheight="0"
marginwidth="0">Loading…</iframe>
</div>
.form-embed {
max-width: 700px; /* forms read badly when very wide */
margin: 0 auto;
}
.form-embed iframe {
display: block; /* kills the stray baseline gap under the frame */
width: 100%; /* overrides width="640" */
border: 0;
height: 1400px; /* see below — you must choose this number */
}
/* On narrow screens every field stacks, so the form gets taller. */
@media (max-width: 600px) {
.form-embed iframe { height: 2000px; }
}
Width is now solved properly and permanently. Height is not solved, and cannot be. Here is why, stated honestly rather than waved at:
Why you cannot auto-size it
Your page is on your domain; the form inside the iframe is served from docs.google.com. That
makes it cross-origin, and the browser's same-origin policy forbids your JavaScript from
reading anything inside that frame — including how tall its content is. The standard escape hatch is for the
framed page to send its height out using postMessage, and the parent to listen. That
requires cooperation from the framed page, and Google Forms does not do it.
So there is no snippet, library or clever trick that makes a stock Google Forms embed grow to fit its
content. Anything claiming otherwise is either measuring nothing, or is not really a Google Forms embed.
What you are actually choosing between — the height="800" in the snippet
above is the number under discussion:
| Height you set | What the visitor gets | Verdict |
|---|---|---|
| Shorter than the form | A scrollbar inside the frame. Two nested scroll regions; trackpads and phones fight over which one moves. | Avoid |
| Taller than the form | Blank space below the submit button. Slightly untidy, but the page scrolls normally and nothing is hidden. | Prefer this |
| Roughly exact | Ideal — until you add a question, or a validation error appears, or someone opens it at a text size you did not test. | Fragile |
Set the height generously. Dead space is a cosmetic flaw; an inner scrollbar is a usability one, and it hides your submit button from people who do not realise they are meant to scroll a box rather than a page. Measure your own form once by opening the responder link on a phone and on a laptop, then round up. Embedding without scrolling is the long version of this decision, including why the auto-resize scripts cannot work.
A page-height variant
If the form is the main thing on the page, letting it fill the viewport can look deliberate rather than approximate:
.form-embed iframe {
display: block;
width: 100%;
border: 0;
height: 100vh;
min-height: 700px;
}
The trade is the same one in different clothes: you have bought a tidy frame at the cost of a guaranteed inner scrollbar on anything but a very short form. Use it for a one-question sign-up; do not use it for a thirty-field application.
What embedding does not change
This trips people up more than the CSS does. An embed is a display change, nothing more:
- The form still lives in Google Forms. You have not copied it onto your site. Edit it in Google Forms and the embed updates, because the embed is a live view of the same form.
- Responses go to exactly the same place. The same Responses tab, the same linked spreadsheet, the same notifications. There is no second bucket to reconcile.
- Your form's settings still apply — sign-in requirements, response limits, the open-and-close schedule, the confirmation message. Embedding does not relax any of them.
- The plain link keeps working. Embedding is additive; it does not retire the responder URL. For the other ways to get a form in front of people, see how to share a Google Form.
What breaks
Forms that require sign-in
This is the one genuinely fragile case, and it is worth reading Google's own wording carefully. Under “Limit users to one response”, Google states: “To access and fill out the form, users must sign in to their Google Account.” Separately, on access: “Before owners publish a form, they can restrict the access to a domain, trusted audience, or group of users.”
Neither sentence is about embedding — Google says nothing specific about how a sign-in-gated form behaves inside somebody else's page. But the consequence is straightforward: a visitor who is not signed in, or who is outside the permitted audience, does not get a usable form in your embed. My advice, not Google's: if your form requires sign-in or is restricted to an organisation, always place the plain responder link directly beneath the embed. It costs one line and it is the difference between a confused visitor and a completed response.
Editors that eat the tag
Rich-text fields, comment boxes and some hosted site builders strip <iframe> on save.
If your embed renders as visible text, or silently disappears when you publish, you are in a sanitised
field. Find the raw-HTML or custom-HTML block instead.
The confirmation screen is inside the frame
After submitting, Google's confirmation message renders inside the iframe. If the frame is scrolled down, a visitor can submit and see no obvious acknowledgement. Another argument for a height that fits the whole form.
Private-window testing
You are signed in to your own Google account, so your embed always works for you. Open the published page in a private window before you call it done — that is the only way you see what a stranger sees.
Editing the form once it is embedded
Because the embed is a live view, changing the form changes what is on your site — which makes fixing a typo or adding a question something you may want to do without opening a laptop. That is where Forms+ fits on this page: it is a native iPhone and iPad client for your real Google Forms on your own Google account, so edits you make there appear in the embedded form on your website. It does not create the embed code — that dialog is desktop Google Forms — but it covers the editing afterwards, and reading the responses that come in.
Edit your embedded form from your phone
Forms+ opens your real Google Forms on your own account. Change a question and your website embed shows it — no laptop, no copy of the form to keep in sync.
Get Forms+ free on the App StoreFrequently asked questions
Why does my embedded Google Form have its own scrollbar?
Because the iframe Google gives you has a fixed pixel height, and your form is taller than it. The iframe does not grow to fit its contents, so anything past that height scrolls inside the frame. Raising the height in CSS until the whole form fits removes the inner scrollbar and lets the page scroll instead.
Can an embedded Google Form resize itself to fit the form?
No. The iframe is cross-origin — it is served from docs.google.com while your page is on your
own domain — so your JavaScript cannot read the height of the document inside it, and Google Forms does not
post its height out to the parent page. There is no auto-height trick that works on a plain Google Forms
embed. You pick a height and accept either a little dead space or an inner scrollbar.
Do responses from an embedded form go somewhere different?
No. Embedding only changes where the form is displayed. It is still the same form living in Google Forms, and responses land in the same Responses tab and the same linked spreadsheet as submissions from the plain link. There is no separate copy and no separate response set to reconcile.
Can I embed a Google Form that requires sign-in?
You can paste the code, but it is the fragile case. Google documents that when you limit users to one response, users must sign in to their Google Account to access and fill out the form, and that owners can restrict access to a domain, trusted audience, or group of users before publishing. A visitor who is not signed in, or not in the permitted audience, will not get a usable form inside your page. Put the plain responder link next to the embed as a fallback.
Why is my embed showing a blank box or nothing at all?
The three usual causes are a page builder that stripped the iframe tag because it was pasted into a rich text field instead of a raw HTML block, a form that has not been published or whose access is restricted so the visitor cannot load it, and a host or security policy that blocks framing third-party content. Open your published page in a private window to see it as a stranger would.