Embedding a Google Form takes about thirty seconds. Getting it to sit on the page as though it belongs there takes rather longer, and the reason is worth understanding before any CSS gets written: the form is not on your page. It is a separate Google page displayed inside a window on your page, and almost every frustration that follows comes from that one fact.
This article covers the code, the height problem and the fix for it, what can and cannot be restyled, and the two things the embed cannot do at all.
The code, and the switch that has to be on first
In Google Forms, open the More menu at the top right and choose Embed HTML, then Copy. What comes back is an iframe whose source is the form's own URL with ?embedded=true appended, plus fixed pixel values for width and height. The Google help page on publishing and sharing a form lists it alongside the other ways to distribute a form.
<iframe
src="https://docs.google.com/forms/d/e/FORM_ID/viewform?embedded=true"
width="640" height="800"
frameborder="0" marginheight="0" marginwidth="0">
Loading...
</iframe>
The embedded=true parameter is what strips the Google page furniture, so the frame shows the questions rather than a full Google Forms page with its header. Removing that parameter is the usual cause of an embed that looks like a screenshot of a different website.
Before testing any of it, check the form's publish state. Google is explicit that a form has to be published before responders can access it, and that if the form is unpublished, responders holding the link cannot get in. The Publish button is at the top right of the form editor. An unpublished form embedded on a live page shows visitors a wall, and since the form owner is signed in, the owner sees the form perfectly and concludes the embed works.
The height problem, and the wrapper that solves it
The copied code carries a fixed height in pixels, and a fixed height is wrong on almost every screen. The same form is short on a desktop and tall on a phone, because the questions wrap. Too short and the visitor gets a scrollbar inside a scrollbar. Too tall and there is a field of empty white between the last question and the next section of the page.
Most form tools solve this by shipping a small script next to the plain iframe. That script works because the vendor's page inside the frame measures itself and posts its height out to the parent. Google Forms does not do this, and the browser's same origin rules mean your page cannot measure the frame's contents itself. There is no way to read the height, so it has to be decided in advance.
Two approaches work. The first is a wrapper that makes the frame fluid in width and generous in height, with the scrolling handled by the frame only when it is genuinely needed.
.form-embed {
width: 100%;
max-width: 720px;
margin: 0 auto;
}
.form-embed iframe {
display: block;
width: 100%;
height: 1100px;
border: 0;
}
@media (max-width: 600px) {
.form-embed iframe { height: 1500px; }
}
The numbers there are not universal, and they should not be copied without checking. Load the published page on a desktop and on a phone, look at where the submit button sits, and raise the height until the button is visible without an inner scrollbar. Then leave a little extra, because a validation error message pushes the form taller than it was when measured.
The second approach is to stop embedding. A button linking to the form's own hosted URL gives the visitor a full width page built for filling in, with no frame and no height to guess. That costs one click. Whether the click matters is a genuine question, and for a long form on a phone the answer is usually that it does not, because a full page beats a window every time.
What can be restyled, and what cannot
Everything inside the frame belongs to Google, and the browser will not let your stylesheet reach into it. That rule has no exceptions and no workaround, so the styling options are exactly those Google provides inside the form editor: a theme colour, a background colour, a header image and a choice of font pairings.
What that means in practice is a form which is recognisably a Google Form, sitting inside a page that is recognisably yours. Sometimes the mismatch does not matter. On a page where the design is the point, or where the form is the main thing the visitor came to do, it does.
| What you want | Possible with a Google Form embed |
|---|---|
| Fluid width | Yes, with a CSS wrapper |
| Frame that grows with its contents | No, there is no resizer script and the height cannot be read |
| Your own typeface and spacing | No, only the font pairings inside Forms |
| Your own field styling and error messages | No |
| One question per screen | Yes, as a Forms presentation setting |
| Send the visitor to a page of your own after submit | No, only an editable confirmation message |
| File attachments without the visitor signing in | No |
That last row surprises people. Google states that to answer a file upload question, responders need to sign in to a Google Account, and that the question type is unavailable when the form sits in a shared drive or when an administrator has turned on Data Loss Prevention. On a public page, a visitor who wants to attach a photograph of the problem meets a sign in prompt, and a proportion of them go away instead.
Prefill, and what it is actually good for
A Google Form can be opened with answers already filled in. In the form editor, the More menu has a Pre-fill form option: fill in the answers to keep, press Get link, and the resulting URL carries those answers as parameters. Append &embedded=true to that URL and it works inside a frame as well.
The obvious use is small and real. If the same form serves four regions, four prefilled links save every visitor a dropdown. If a form is linked from six different pages, prefilling a hidden source field means the response arrives knowing where the visitor came from, which is more reliable than asking them.
What prefill cannot do is identify the visitor, unless your page already knows who they are and can build the link at render time. On a public marketing page it does not know, so the email address still has to be typed.
Two settings to change before the form goes live
The confirmation message. Google Forms offers an editable confirmation message under Settings, then Presentation. The default says the response was recorded, which tells the visitor nothing they need. Replace it with the two facts they actually want: how long a reply takes, and what to do if it is urgent. Inside a frame this message appears in the frame, so the visitor stays on your page, which is one small advantage the embed has over linking out.
The results summary. Also under Presentation is View results summary, which shares a summary of responses with everyone who can answer the form. Google's own documentation notes that response summaries are visible to anyone who can respond. For an internal poll that is useful. On a public contact form it means every visitor can read what previous visitors wrote, and it is switched on by accident more often than anyone would like.
Closing the form, and what the frame shows when it is closed
An embedded form on a live page keeps accepting answers until something stops it, and for anything with a deadline that something should be set in advance rather than remembered on the day. In a published form, clicking Published at the top right reveals an Accepting responses switch, and next to it the option to set a close date or a response limit. Give it a date and time, or a maximum number of responses, and the form stops by itself.
What the visitor then sees inside the frame is a short notice that the form is no longer accepting responses, and that notice can be replaced with wording of your own. This is worth five minutes, because a frame containing a bare refusal on a page that still advertises the thing being applied for reads as a broken site rather than a closed intake. Say that it has closed, when the next round opens, and where to write in the meantime.
One related limit catches teams who distribute the same form by email as well as embedding it. Google notes that a form cannot be embedded in an email if it contains a file upload question, a rating question, an image inside a question or an option, or a secured quiz. Any of those and the email carries a link instead, which is fine, but it means the form that works nicely in a frame behaves differently in a mailout.
What the embed cannot carry, which is the reply
The embed ends at the submit. From there the response sits in the form's Responses tab, and the only push notification available is under Responses, then the More menu, then Get email notifications for new responses, documented on the page about viewing and managing responses. It is one switch, on or off.
That switch tells watchers something arrived. It carries neither of the two fields that a shared form needs.
The first is an owner. When three people get the notification, nothing in it says which of the three is replying. Everyone reads it, most assume it is covered, and the two familiar outcomes follow: the visitor who gets two different answers in an hour, and the visitor who gets none at all.
The second is a status. New, waiting on the visitor, and finished are different things, and a response list with no way to tell them apart has to be read from the top every week to find out what is still open. The usual patch is a column added to the linked spreadsheet and filled in by hand. It holds up at twenty responses a month and falls apart somewhere near two hundred, at which point nobody trusts the column enough to use it.
This is not a criticism of the embed. Collecting answers is the job it does, and it does it for nothing. But if the form is the front of a process where somebody replies, the embed is one third of the work, and the other two thirds are currently living in an inbox. A form tool that holds an owner and a status against each response, and sends the reply from the same screen, answers the questions that an inbox cannot: who has this one, what was said in March, and how many are still open right now. The list itself makes that clearer than a description does, and the worked examples show where it earns its keep and where a spreadsheet column is still fine.
What to change first
Embed the form today with a CSS wrapper rather than the pasted pixel height, check it on a phone, and press Publish on the form itself as well as on the page. Then rewrite the confirmation message, because it is the only thing the visitor sees and it currently says nothing. If two or more people are going to answer what comes in, decide where the owner and the status are going to live before the volume arrives, since a list that already holds both costs less than the spreadsheet column that will otherwise be built by hand.
Q1. Where is the embed code for a Google Form?
Open the form, click the More menu at the top right, choose Embed HTML, and copy what appears. It is an iframe pointing at the form's own URL with ?embedded=true appended. Keep that parameter, since removing it brings back the full Google page furniture inside the frame.
Q2. Why is there empty space below the embedded form, or a scrollbar inside it?
Because the copied code sets a fixed pixel height and the form's real height changes with screen width. Replace the fixed height with CSS that sets the width to 100 percent and a height generous enough for the narrowest screen, then check the published page on a phone. Google does not provide a script that resizes the frame, and same origin rules prevent your page from measuring it.
Q3. Can the embedded form be styled to match the site?
Not beyond the options inside Google Forms, which are a theme colour, a background colour, a header image and a choice of font pairings. The form is a separate page inside a frame, so your stylesheet cannot reach it. Exact control of appearance requires a form built as part of your own page.
Q4. Can the visitor be sent to a thank you page after submitting?
Not with a Google Form. The available setting is an editable confirmation message, which appears in place of the form. Inside an embed that means the visitor stays on your page, which is useful, so the message is worth rewriting to say how long a reply will take rather than leaving the default.
Q5. Does the embedded form work if respondents are not signed in to Google?
Yes for ordinary questions, provided the form is published and set so that anyone with the link can respond. Two settings break it: a file upload question requires a signed in Google Account, and limiting the form to one response per person also requires sign in. Both turn a public contact form into one that only Google account holders can complete.