Every form tool offers an embed, and the word covers three quite different things. One of them is a window onto someone else's page. One is a script that builds the form in yours. One is markup you own that posts somewhere else. They look the same in a demo and behave differently the moment the page is on a phone, behind a content security policy, or inside a page builder that will not accept JavaScript.
This is a guide to choosing between them, to what each platform will actually let you paste, and to the part of the job that no embed does for you.
The three shapes, and how to tell them apart
Look at what the vendor gives you to copy. That single snippet decides most of what follows.
An iframe is a window. The form is a separate page, served by the vendor, displayed in a rectangle on yours. Your stylesheet cannot reach into it, your JavaScript cannot read it, and the rectangle has whatever size you give it.
A script tag loads code from the vendor which then builds something in your page, usually still an iframe but a managed one. Because the vendor controls both sides, the frame can report its own height outwards and be resized to fit, and the same script can offer the form as a popover, a side tab or an inline block.
Your own markup is a plain HTML form whose action points at an endpoint. Nothing is loaded from anyone. The form is part of your page in every sense, including that it inherits your typography for free.
| iframe | Script tag | Your own markup | |
|---|---|---|---|
| Matches your typography | No | No, but themable | Yes, automatically |
| Grows to fit its contents | No | Usually yes | Not applicable |
| Popover or side tab modes | No | Usually yes | Build it yourself |
| Works with JavaScript blocked | Yes | No | Yes |
| Validation, logic, uploads included | Yes | Yes | You build them |
| Blocked by strict page builders | Sometimes | Often | Rarely |
There is no winner in that table. An iframe is the most robust and the least attractive. A script tag is the most comfortable and the most likely to be refused. Your own markup is the most native and the most work.
Why the script tag is usually the right paste
If the platform allows it, the script version solves the problem that ruins most embeds, which is height.
A plain iframe has to be given a pixel height in advance, and the right height changes with screen width because the questions wrap. Set it for a desktop and phone visitors get a scrollbar inside a scrollbar, which is the single most reliable way to lose someone mid form. Set it for a phone and desktop visitors get a field of white space. The script version avoids the guess: the page inside the frame measures itself and posts the number out to the parent, which resizes the frame. Nothing to tune, nothing to re check when a question is added.
Two other things come with the script and are worth having. The first is the choice of presentation. The same form can sit inline in the page, appear as a popover after a delay or a scroll depth, or live behind a tab on the edge of the screen. For a contact form, inline on a page of its own is almost always right, and the popover is almost always wrong, but having the option costs nothing.
The second is that the script can pass values from your page into the form. Which page the visitor was on, which plan they were reading about, which campaign brought them: all of it can arrive attached to the response rather than being asked for. This is more accurate than a dropdown, because visitors answer questions about themselves badly and pages know the truth.
What your platform will actually accept
This is the step that gets skipped, and it decides everything above. Page builders differ sharply on what they let through, and some of them draw the line exactly between the iframe and the script.
Squarespace is a clear example, and a documented one. Its code blocks accept plain text, HTML, Markdown and CSS inside style tags on every plan, but adding JavaScript or iframes to a code block is available on the Core, Plus, Advanced, Business, Commerce Basic and Commerce Advanced plans, as set out on the Squarespace page about code blocks. On the entry level plan, both embed routes are closed, and the only remaining option is the platform's own form block or a link out to the hosted form.
Google Sites takes the opposite approach and allows both. Insert, then Embed offers a URL field and an Embed code field, and Google documents that the code field accepts HTML, CSS and JavaScript, with JavaScript inside script tags and CSS inside style tags, as described on the Google Sites help page for adding content. The embed can also occupy a whole page rather than a block.
WordPress accepts anything in a custom HTML block on a self hosted site, and much less on the hosted service's lower tiers. Notion and similar document tools accept a URL and render it in a frame, with no script tag and no height control worth the name.
On a site you build yourself there is a second gate, and it is quieter. A content security policy that lists which origins may be framed or may serve scripts will block an embed without any visible error beyond an empty space and a line in the browser console. Adding the vendor's domain to the relevant directives is a two minute change for whoever owns the configuration, but it has to be asked for, and it is usually discovered by someone who has already concluded the embed code is broken. Check the console on the published page before reporting a fault to the vendor.
The order of operations, then, is the reverse of what people do. Find out what the platform accepts, then pick the embed shape, then build the form. Choosing a form tool for a feature that arrives only in its script tag, and then discovering the site cannot host a script tag, is a wasted afternoon that happens constantly.
Five checks that decide whether it feels native
An embed that technically works can still feel pasted in. Five things account for most of the difference, and all five are quick.
Width before styling. Set the frame or container to 100 percent width with a sensible maximum, and centre it. A form that is narrower than the text above it looks like an advert; one that runs the full width of a wide screen is unreadable. Somewhere around 600 to 720 pixels of maximum width suits a single column form.
Scroll position on error. When validation fails inside a frame, the frame scrolls to the error and the page does not, so on a long page the visitor can see a submit button that did nothing and no message anywhere. Scripted embeds usually handle this. With a plain iframe, keep the form near the top of its section so the whole frame is in view.
Fonts, or the honest acceptance of them. An iframe will not inherit your typeface. Either use the vendor's closest available font and accept the mismatch, or stop embedding and link out to a full page where the mismatch does not sit next to your own text.
What the visitor sees after submit. The default is usually a line of vendor text saying the response was recorded, which tells the visitor nothing. Replace it with how long a reply takes and what to do if it is urgent. If the tool supports a redirect, point it at a page on your own domain, because that page can carry the next step.
The phone, on the published page. Not the editor preview, not a narrowed desktop window. Published, on a real phone. Every height and scrolling problem in this article shows up there and nowhere else.
The part the embed does not cover, and the privacy note it needs
Two consequences of embedding are easy to miss because they are not visual.
The first is measurement. A form inside a frame is a different origin, so your analytics does not see the fields being filled or the submit being pressed unless the vendor sends an event out to the page. Conversion on that page therefore reads as zero, and a team optimising the page ends up flying blind. Check whether the tool posts a submit event to the parent, and if it does not, use the thank you page on your own domain as the thing you count.
The second is disclosure. An embed loads a third party into your page and that party receives whatever the visitor types, including their name and email. Whatever privacy notice the site carries needs to say so, and if the site asks for consent before loading third parties, the form may need to sit behind that consent, which means a visitor who declines sees an empty rectangle. A link to a hosted form sidesteps the whole question, since nothing third party loads until the visitor chooses to go there.
What no embed does for you
Every route in this article ends at the same place. A response exists somewhere and somebody has to answer it.
For one person answering ten a week, the vendor's notification email is enough. The trouble starts at two people and one shared inbox, and it always takes the same three forms. Two people answer the same message differently within the hour, because nothing said which of them owned it. A message gets no answer at all, because everyone assumed it was covered. And a month later nobody can say what was promised to a particular enquirer, because the record is in somebody's sent items and depends on that person still working there.
What is missing is not a better form. It is two fields against each response: an owner, so exactly one person is answerable, and a status, so that new, waiting and finished are visible states rather than shared assumptions. Teams add them by hand at first, as a column in an exported spreadsheet or a label in the inbox, and the hand filled version holds up to roughly two hundred responses a month before it stops being believed.
A form tool that keeps those two fields next to the answers, and sends the reply from the same screen, makes the ordinary questions answerable without asking anyone. The response list with owners and stages is the part worth looking at rather than the form builder, since the builders are all much the same and this is where the time goes. The worked examples show which intakes justify it and which are still fine on a spreadsheet column.
What to change first
Find out what your platform accepts before choosing anything, then paste the script version if it is allowed and the iframe if it is not, and test the published page on a real phone. Rewrite the message the visitor sees after submitting, since it is currently the vendor's and says nothing useful. If more than one person will answer what arrives, look at a list that already carries an owner and a status before building the spreadsheet column that would otherwise do the job by hand.
Q1. What is the difference between the iframe and the script tag a form tool offers?
The iframe is a window onto the vendor's own page, with a height you set by hand. The script tag loads vendor code that builds and manages the frame inside your page, which lets it resize itself to fit its contents and offer popover or side tab modes. Use the script where the platform allows it, because the height problem disappears.
Q2. Can an embedded form be styled to match the site?
Only through whatever theming the vendor exposes. The form is served from a different origin, so your stylesheet cannot reach inside the frame and there is no workaround for that. A form that must match the site exactly has to be built as part of the page, with its submissions posted to a service or a server.
Q3. Why does the embedded form have empty space below it, or scroll inside itself?
Because a plain iframe was given a fixed pixel height and the real height of the form changes with screen width. Switch to the vendor's script version if the platform permits it, since that resizes the frame automatically. If it does not, set a height that works on the narrowest screen and accept the white space on wide ones.
Q4. Do embedded forms work if the platform blocks JavaScript?
A plain iframe does, since it needs no scripting on your side. A script tag embed does not, and some page builders restrict both to their paid tiers. Check the platform's documentation on code blocks before choosing the tool, because this constraint decides which embed shape is available.
Q5. Does an embedded form need mentioning in the privacy notice?
Yes. The embed loads a third party into the page and that party receives what the visitor types, including their name and email address. If the site asks for consent before loading third parties, the form may sit behind that consent, in which case a visitor who declines sees an empty space where the form should be.