Embedding a form is copying a snippet into a page. Embedding one that works on every device, does not shift the layout, and actually converts takes slightly more thought.
The decision that matters is which kind of embed, and it depends entirely on where the form sits in what somebody is doing.
Inline, which is the default for a reason
The form appears in the page, in the flow of the content, as though it were part of it. No overlay, no click required, nothing to dismiss.
This is right whenever the form is the point of the page, or the natural end of it: a contact page, the bottom of a pricing page, a signup section. People arrived expecting to do something and the thing is there.
The one thing to get right is height. An inline embed that guesses wrong leaves either a scrollbar inside your page or a stretch of white space under the form. A good embed resizes itself as the form changes, which matters a lot on a multi-step form where each step is a different length.
Popup and slide-in, which cost more than people think
A popup gets more eyes and less goodwill. It works when the offer is genuinely relevant to the page and the timing is reasonable, and it is actively harmful when it interrupts somebody mid-sentence on their first visit.
If you use one: trigger on exit intent or on scroll depth rather than on a timer, never on the first few seconds, make it dismissible with an obvious control, and do not show it again to somebody who closed it.
On phones, be careful. Google treats intrusive interstitials on mobile as a ranking problem, and a popup that covers the content somebody came to read is exactly that. A slide-in from the bottom is usually the safer version.
Full page, for when the form is the whole job
Linking to the hosted form rather than embedding it. No surrounding page, no competing navigation, nothing else to click.
This is right for applications, long surveys and anything where you want complete attention. It also sidesteps every embedding problem at once, which is worth more than it sounds when you are debugging at eleven at night.
The cost is that people leave your site. On a paid plan you can serve the form from your own domain, which removes most of that objection: the address still says your name.
The problems that are genuinely hard to debug
In rough order of how often they catch people out.
- The form appears but is cut off. The container has a fixed height, or an overflow rule is clipping it. Look at the parent element, not the embed.
- It works on desktop and not on a phone. Almost always a fixed width somewhere in the container. The embed needs a container that can be narrow.
- A content security policy blocks it. If your site sets one, the form's origin has to be allowed in frame-src. The error shows in the browser console and nowhere else.
- It loads twice. Usually the snippet is in both a template and a page. Harmless-looking and it breaks analytics.
- Layout shift when it loads. Reserve the space with a minimum height on the container so the page does not jump.
- Nothing appears at all. An ad blocker, or the script tag placed somewhere the page strips. Check with blocking off before assuming the worse explanation.
An inline embed that guesses its height wrong leaves either a scrollbar inside your page or a stretch of white space under the form.
Platform notes
The mechanics vary slightly and the traps are consistent.
- WordPress. Use a Custom HTML block, not a paragraph. The visual editor will strip a script tag pasted into prose.
- Squarespace and Wix. An embed or code block. Both sometimes sanitise scripts on lower plans, in which case use the iframe version.
- Webflow. An Embed element. Remember to publish; the staging preview often renders it and the live site has not been updated.
- Shopify. A custom Liquid section, or the page's HTML editor. Watch for theme styles overriding the container width.
- Framer and Notion-based sites. Both prefer an iframe URL to a script.
- A plain HTML site. Either works. Put the script just before the closing body tag.
Two things worth doing after it works
Pass the page into the form as a hidden field, so every response arrives knowing where it came from. If the same form is embedded in four places, this is the difference between useful data and a single undifferentiated pile.
Then fill it in yourself from the live page, on a phone, and check the response arrives. Testing in the form builder's preview is not the same thing, and the gap between them is where embedding problems live.
Which embed converts best
The honest answer is that it depends on intent, and the pattern is consistent enough to plan around.
On a page somebody arrived at in order to do the thing, inline wins comfortably. There is no step between reading and starting, and nothing to dismiss.
On a page somebody arrived at to read something else, a popup gets more submissions and a worse audience. The people it catches were not looking for your form, which shows up later as lower-quality leads and higher unsubscribes.
For anything long or important, full page wins, because every other thing on the page is competing with the form for attention and the form is the only one you want to win.
Keeping track of where submissions came from
The same form embedded in six places produces one pile of responses unless you do something about it, and the something is one hidden field.
- Pass the page URL in, so every response knows which page it came from.
- Pass campaign parameters through. They arrive in the URL and disappear on the first navigation unless you capture them.
- Pass anything your site already knows: a plan name, a product id, a logged-in account reference.
- None of this is visible to the person filling the form in, and all of it is the difference between a dashboard you can act on and a list of names.