Short answer: in Google Forms, click Send > Embed (
<>
), copy the iframe code, then paste it into a Custom HTML block in your WordPress post or page. Set a width that matches your content area (typically 640-720 pixels), publish, and the form is live. No plugin required.
The rest of this guide covers the embed flow step by step, why some embeds appear blank or oversized, the styling and CAPTCHA tradeoffs of Google Forms versus a native WordPress form plugin like WPForms or Gravity Forms, the GDPR and privacy implications of loading Google services on your site, and how to keep the embed responsive on mobile.
Quick embed: the iframe path#
This is the simplest path and works on any WordPress site.
- Open your form in Google Forms.
- Click the Send button (paper plane icon, top right).
- In the Send dialog, switch to the Embed (
<>) tab. - Set the width and height. Default is 640×800 pixels – keep that for most cases. Mobile browsers will scale it down automatically.
- Click Copy to copy the full iframe HTML.
- In your WordPress post or page, click + to add a block, type HTML, and pick the Custom HTML block.
- Paste the iframe code into the block.
- Click Preview at the top of the block to check the form rendered correctly.
- Update or Publish the post.
That is the entire flow. The form is now embedded, submissions go to your Google Forms response sheet, and you do not need any plugin to manage it.
If you are new to the Custom HTML block or you find your pasted iframe rendering as literal text, how to add HTML to a WordPress post or page covers the block in depth, including the user-role permissions that decide who can paste raw HTML at all.
Making the form responsive#
The default Google Forms iframe is fixed-width. On a phone the form might overflow horizontally or shrink awkwardly. Wrap it in a div with responsive CSS so it scales with the screen.
Replace the default iframe with this in your Custom HTML block:
<div style="position: relative; width: 100%; max-width: 720px; margin: 0 auto;">
<iframe
src="https://docs.google.com/forms/d/e/YOUR_FORM_ID/viewform?embedded=true"
style="width: 100%; min-height: 800px; border: 0;"
loading="lazy"
title="Contact form">
Loading...
</iframe>
</div>
Three small changes from the default:
-
width: 100%lets the iframe fill the available column width on any screen size. -
loading="lazy"defers loading until the iframe is near the viewport. Important – the Google Forms iframe pulls hundreds of kilobytes of JavaScript and CSS, and lazy-loading keeps that out of the initial page load. -
titleis the accessible name screen readers announce. Always set this.
You can keep the height fixed at 800 or whatever the original embed showed. Google’s iframe handles its own internal scrolling if the form is taller than the iframe height, but most users prefer the page to scroll naturally rather than scroll-within-an-iframe. Set the height to roughly 100 pixels per question and round up.
For sites where forms appear in posts often, consider adding the wrapper styles to your theme’s CSS once with a class name, then writing only
<iframe class="gforms-embed" ...>
in each Custom HTML block. The edit and add custom CSS guide covers where the CSS goes.
When Google Forms is the right choice#
Embedded Google Forms work best when:
- You need it live in 5 minutes. No plugin install, no settings to learn, no theme integration. Build the form in Google Forms, paste the iframe, done.
- You want responses in a Google Sheet. Form data flows automatically into the linked sheet, where you can pivot, filter, share, or pipe into Zapier and other tools.
- You do not need styling control. The form looks like a Google Form. White background, Google’s typography, Material-style inputs. You can pick a header color and a font in Google Forms itself, but you cannot match your site’s design beyond that.
- You want Google’s spam protection. Forms includes basic CAPTCHA on suspicious submissions, and the Google account requirement (when enabled) blocks bulk spam.
- You do not collect data through this form that needs to live in WordPress. The submissions never touch your WordPress database, which is both a feature (no extra surface area, no plugin to maintain) and a limitation (you cannot trigger WordPress actions on submission, you cannot follow up via the WordPress user system).
When a native WordPress form plugin is the right choice#
A WordPress-native form plugin (WPForms, Gravity Forms, Fluent Forms, Forminator, Contact Form 7) is the better path if any of these apply:
- Styling has to match your site. Native plugins inherit your theme’s typography, colors, and spacing. The form looks like part of the page, not an iframe pasted on top of it. Google Forms cannot match a custom design.
- You need conditional logic. “If they pick Option B, show the secondary question; otherwise hide it.” Google Forms has section-based branching, which is coarse. WPForms and Gravity Forms handle conditional logic at the field level, which is much more flexible.
- Form data needs to stay in WordPress. Native form plugins store submissions in your WordPress database, send notification emails, integrate with WooCommerce orders, register users, trigger membership signups, or push data to your CRM. None of that is possible with a Google Forms embed.
- You need stronger spam protection. Native plugins integrate with Akismet, hCaptcha, Cloudflare Turnstile, and honeypots that are usually more effective than Google Forms’ built-in CAPTCHA. They also let you tune the rules.
- You do not want to introduce a third-party iframe. Iframes add a separate request chain, third-party cookies, and a layout-shift risk. Native forms are inline HTML rendered by your own server, so page speed and Core Web Vitals are typically better.
- You care about data residency and GDPR. A WordPress form keeps the submission data on your hosting infrastructure (or wherever your database lives). A Google Forms embed sends data straight to Google.
The rule of thumb: Google Forms is fine for internal surveys, RSVP forms, simple feedback collection on a small site. For anything that takes leads, registrations, payments, or sensitive data on a public website, use a native WordPress form plugin.
Privacy and GDPR implications#
This is the part most “embed Google Forms in WordPress” tutorials skip, and the part most likely to bite a non-EU site that gets EU traffic.
When a visitor loads a page with a Google Forms iframe, their browser:
- Connects to
docs.google.comto fetch the form HTML. - Loads JavaScript and CSS from
gstatic.comand other Google domains. - Sends the visitor’s IP address, user agent, and referrer to Google.
- Receives Google cookies, including identifiers tied to the visitor’s Google account if they are logged in.
Under the GDPR and the ePrivacy Directive, all of that counts as personal data processing. The legal exposure depends on where the visitor is and what your site is doing:
EU and UK visitors. You need a legal basis for the processing. The standard approach is consent via a cookie banner that gates third-party embeds until the visitor agrees. Until they consent, the iframe should not load – meaning a placeholder, a “click to load Google Forms” button, or no iframe at all. Loading a Google Forms iframe by default for an EU visitor without consent is a textbook GDPR violation.
California visitors (CCPA/CPRA). Less strict than GDPR but still requires a “Do Not Sell or Share My Personal Information” mechanism if you are subject to it. A Google Forms embed counts as sharing data with a third party.
Other US states. Privacy laws vary by state. Most do not require consent for analytics-style processing but may require disclosure in your privacy policy.
The pragmatic approaches:
- Use a consent management plugin (Complianz, CookieYes, Real Cookie Banner) that blocks third-party iframes until the visitor consents. The plugin replaces your iframe with a placeholder until then.
- Add a manual placeholder. Replace the iframe with a “Click to load form” button that swaps in the iframe via JavaScript on click. Cheap, no plugin needed, but you lose the seamless embed.
- Switch to a native WordPress form. No third-party data flow, no consent banner needed for the form itself, no iframe to gate.
Document whichever approach you take in your site’s privacy policy. List Google as a data recipient, link to Google’s privacy policy, and explain what data the form collects.
Embedding Google Forms via shortcodes or plugins#
A handful of plugins exist to “improve” Google Forms embeds. Most of them do one or more of:
- Re-style the form to match your theme by injecting custom CSS into the iframe (which usually fails – cross-origin restrictions block iframe styling).
- Convert a Google Forms URL into a shortcode for non-technical authors.
- Mirror the form’s questions in a native WordPress form plugin and forward submissions to the Google Sheet via the API.
For most sites, the plugins are not worth the trouble. The iframe + Custom HTML block path is faster, has fewer moving parts, and survives plugin updates and theme switches. If you want native styling, just use a native form plugin from the start – those mirror plugins are essentially WPForms or Gravity Forms in a thin wrapper anyway.
The one exception: if you have non-technical staff who routinely paste Google Forms into posts and they cannot be trusted with raw HTML blocks, a shortcode-based plugin like “Google Forms by Wpsoul” is a reasonable abstraction. It exposes a
[google_form]
shortcode that takes the form ID and renders the iframe with sensible defaults.
Common embedding mistakes#
Pasting the share URL instead of the iframe code. The Send dialog has three tabs: Email, Link, and Embed. Only the Embed tab gives you the iframe HTML. The Link tab gives a URL that will not embed – if you paste it into a Custom HTML block, you get a clickable link, not the form.
Using the wrong form ID. Google Forms has two IDs: the editor URL (
/forms/d/<id>/edit
) and the public viewform URL (
/forms/d/e/<id>/viewform
). The embed iframe always uses the second one. If your iframe
src
contains
/edit
, the embed shows the editor and visitors get a permission error.
Setting iframe height too short. If the form is 1,200 pixels tall and you set height to 600, the form scrolls inside its iframe, which feels broken. Set the height to roughly 100 pixels per question, or use a JavaScript snippet to auto-resize the iframe based on its content (cross-origin restrictions make this tricky for Google Forms specifically).
Missing the title attribute. Iframes without a
title
attribute fail accessibility audits. Screen readers announce iframes, and without a title they announce the URL or “frame” – not useful. Always add
title="Contact form"
or similar.
Forgetting
loading="lazy"
. A Google Forms iframe pulls hundreds of KB of JavaScript and CSS at page load. If the form is below the fold, lazy-loading defers all of that until the user scrolls near it. The page loads faster, the Largest Contentful Paint metric improves, and the form still works when the user reaches it.
Embedding the form on a private page without testing the share permissions. If your form’s “Limit to 1 response” or “Restrict to organization” settings are on, embedded form visitors hit a Google sign-in wall. Always test the embed in a private/incognito window before publishing.
Embedding on a password-protected page and expecting form submissions to be similarly protected. WordPress’s page password gates page access, not what happens inside the iframe. Submissions still flow to Google whether or not the visitor entered the WordPress password.
Letting the iframe break the page layout. If your theme’s content area is 700 pixels wide and you embed a 640-pixel iframe, fine. If your theme is 500 pixels wide, the form overflows on mobile. Use the responsive wrapper above.
Security and CSP considerations#
If your site uses a strict Content Security Policy, the Google Forms iframe needs explicit allow-listing. The relevant CSP directives:
frame-src https://docs.google.com;
img-src 'self' https://*.gstatic.com;
script-src 'self' https://www.google.com https://www.gstatic.com;
Without those, the form blocks itself with a console error like “Refused to frame ‘docs.google.com’ because it violates the following Content Security Policy directive.”
If your theme or a security plugin sets CSP headers, check the headers (browser DevTools > Network > the page request > Response Headers) for the directives above before assuming the embed is broken.
You can also add the
sandbox
attribute to the iframe for an extra layer of isolation, but Google Forms needs
allow-scripts allow-forms allow-same-origin
to function, which neutralizes most of the sandbox’s value. For a third-party form you trust (Google), sandbox without those three attributes will break the form. For a less trusted iframe source, sandbox makes more sense.
How Hostney handles iframe-heavy pages#
Pages with embedded Google Forms hit two performance edges that Hostney handles transparently. First, the cached HTML from the page cache includes the iframe markup but not the iframe’s contents – the visitor’s browser still fetches Google’s JavaScript and CSS on load. The cache speeds up your page; it does not speed up Google. Second, the Hostney Cache plugin’s automatic purge fires when you edit the page, so adding or removing an embed does not leave a stale cached version showing the wrong content.
For sites with forms on most pages, the bigger performance win is the responsive wrapper above with
loading="lazy"
and a native WordPress form plugin where possible. Both reduce the third-party request load that no host can optimize.
Summary#
The 30-second embed: Send > Embed > copy iframe > Custom HTML block > paste > publish. Wrap it in a responsive container with
loading="lazy"
and a
title
attribute and the embed works correctly on every device.
Use Google Forms when speed-to-publish matters and you do not need native styling, conditional logic, or WordPress-side data integration. Use a native form plugin (WPForms, Gravity Forms, Fluent Forms) when any of those matter, and especially when GDPR or data-residency concerns apply to your audience.
Whatever you embed, document it in your privacy policy and gate it behind a cookie banner if you have meaningful EU traffic. The iframe loading on a non-consent page is the single biggest privacy mistake the standard “how to embed Google Forms” tutorials skip.