Skip to content
Get a free quoteGet a quote
Published
Byline
GoHighLevel Partners Editorial

The seven causes behind a clipped, scrolling or oversized embedded form, and the check that catches each one before a page goes live.

An embedded form that shows its own scrollbar, cuts the submit button in half, or leaves a wide strip of empty space underneath is one of the most common complaints after a new page goes live. The form itself is usually fine. What breaks is the frame around it, and the visitor is left looking at a box whose submit button sits below the edge of something they did not realise was scrollable.

The fix is rarely in the form builder. It is in the boundary between two documents that, by design, cannot see each other.

Why a form embed height issue happens, and how to fix each cause

An iframe cannot be measured from the outside

An embedded form is an iframe: an entire second page loaded inside your page, served from a different domain. The browser’s same-origin policy stops the parent page reading anything inside that document, and that includes how tall its content is. Your page knows the iframe element exists. It has no way of knowing whether the form inside it is four fields tall or forty.

So the height has to be sent rather than read. The embed script that ships alongside the iframe listens for a message posted from inside the form, takes the pixel height it reports, and writes that value onto the iframe element. Every symptom below is a failure of one link in that chain: the message was never sent, it was never received, or it was correct at the moment it was measured and wrong a second later.

The three ways the resize handshake breaks

The embed script was never loaded

If someone copied only the iframe line out of the embed code and dropped it into a custom HTML block, there is nothing on the page listening for the height message. The iframe falls back to its default height, which is a few hundred pixels regardless of the form, and every form longer than that gets an inner scrollbar. Check the page source for the script tag that is supposed to accompany the iframe, then check the browser console for a request that was blocked rather than merely absent.

Two things block it even when the tag is present. A consent manager that files unknown scripts under a non-essential category holds it until a visitor accepts, so the page looks correct to you, who accepted weeks ago, and broken to every first-time visitor. And a performance plugin that defers or combines scripts can move it past the moment the form announced its height, so the message arrives with nobody listening.

The iframe was measured while it was hidden

An element with a display value of none has no layout, and therefore no height. If the form sits inside a tab that is not the default tab, inside a closed accordion, inside a popup, or inside a slider panel that has not been advanced to yet, the height it reports at load time is zero or close to it. Opening the tab then reveals a frame that was sized for nothing.

This is the most common cause on a page that behaves perfectly in isolation and breaks the moment it is dropped into a real layout. The fix is to keep the container in layout while hiding it visually, or to fire a resize when the container opens. A container hidden by an off-screen position or by zero opacity still has a height; a container hidden by display none does not.

The height changed after the page settled

A form with conditional logic, a multi-step form, or a form with a file upload field is taller after the visitor interacts with it than it was at load. So is a form that suddenly shows validation errors under three fields at once. If the embed is the script version, it re-sends on change and the frame follows. If someone hard-coded a height attribute onto the iframe to fix an earlier problem, that hard-coded value now wins permanently, and the form is clipped from the first conditional field onwards.

Symptom to cause, in one table

What you see Most likely cause Where to look first
Inner scrollbar on every device Resize script missing or blocked Page source for the script tag; console for a blocked request
Correct on load, clipped once a conditional field appears A fixed height attribute or CSS height on the iframe The embed code itself, and any custom CSS targeting it
Height of zero, or a thin strip Measured while the container was hidden Tab, accordion, popup or slider state at page load
Wide empty gap below the form A minimum height on the builder row, not on the form Row and column settings in the page builder
Fine on desktop, clipped on mobile Content reflows taller at narrow widths Resize the window slowly and watch whether the frame follows
Works for you, broken for visitors Consent manager holding the script back The cookie category the script is tagged under
Page content jumps as the form appears No space reserved before the height message arrives Layout shift in a field-data report

When your own CSS is the cause

Page builders like to help. A row with a fixed height, a column with an equal-height setting, or a global rule capping the height of every iframe for the sake of video embeds will all override whatever the resize script writes. The script sets an inline height on the element; a stylesheet rule with higher specificity, or one carrying an important flag, beats it silently and leaves no error anywhere.

Test by lifting the form out of the styled section and dropping it into a plain full-width block on a draft page. If it sizes correctly there, the container is the suspect. Work back up the tree one wrapper at a time rather than piling new rules on top of old ones.

Reserve the space before the height arrives

Even a working embed resizes a fraction of a second after the page paints, and everything below it moves down when it does. That movement is measured as layout shift. Give the wrapper a minimum height close to the form’s real rendered height, so the correction is a nudge rather than a jump of several hundred pixels. Set it as a minimum, never as a fixed height, or you reintroduce the clipping this article started with.

When to stop embedding and link instead

Long forms, forms with heavy conditional branching, and forms behind a step wizard are frequently better served as a hosted page you link to. You lose the visual continuity of the surrounding page, and you gain a document that sizes itself natively, needs no handshake, and cannot be clipped by a wrapper it never knew about. The same reasoning applies to survey and calendar embeds, which share the mechanism exactly. If you are also managing when a form is open at all, the guide to form and survey schedule visibility covers the settings that decide what a visitor sees when a form is closed rather than merely short.

A short check before you hand the page over

  1. Load the page in a private window, so that no accepted consent and no logged-in session flatters the result.
  2. Open every tab, accordion and popup that contains a form, and confirm each one sizes itself after it becomes visible.
  3. Fill in the field that triggers the largest conditional branch, and confirm the frame grows with it.
  4. Trigger a validation error deliberately, and confirm the message is not clipped.
  5. Drag the window from desktop width to phone width in one slow movement, and watch the frame follow.
  6. Submit once, and confirm the confirmation state, which is usually a different height again, is fully visible.

File upload fields deserve their own pass, because the frame grows once a file is attached and again if the upload fails. What happens after a successful upload is worth wiring into automation, which the write-up of the client portal file uploaded trigger works through. If the embed is a booking widget rather than a form, the same handshake applies, with the extra wrinkle that a calendar changes height whenever the visitor moves between months, a behaviour worth reading alongside the available days setup guide.

None of this requires touching the form. It requires accepting that the frame is a separate document, that its height is a message rather than a measurement, and that anything delaying, blocking or overriding that message produces one identical symptom.

Frequently Asked Questions

Why does my embedded form show a scrollbar instead of expanding?

The iframe is falling back to a default height because the resize script that receives the form’s height message is missing, blocked or loaded too late. Confirm the script tag was copied along with the iframe, then check the browser console for a request that was blocked.

Can I just set a fixed height on the iframe to fix it?

It works until the form gets taller. A conditional field, a validation message, a file upload or a second step all change the height after load, and a fixed value clips every one of them. Use a minimum height to reserve space and leave the script free to set the real one.

Why is the form fine on desktop but cut off on a phone?

Content reflows taller at narrow widths, so a form that is six rows on a desktop may be twelve on a phone. If the height was measured once at a wide viewport and never re-sent, the frame keeps the desktop value. Drag the window narrow slowly and watch whether the frame follows.

My form has no height until I click the tab it sits in. Why?

An element with display set to none has no layout and therefore no measurable height, so the form reports zero at load. Either keep the container in layout while hiding it visually, or fire a resize when the tab opens.

Why does the form look right for me and broken for visitors?

You accepted the cookie banner once and your browser remembers it. If the consent manager classifies the embed script as non-essential, first-time visitors never load it and they see the unresized fallback. Check which consent category the script is tagged under.

What causes an empty white gap underneath a correctly sized form?

That is almost always the container rather than the form: a row with a fixed height, an equal-height column setting, or padding on the section. Drop the same embed into a plain block on a draft page to confirm the form sizes correctly on its own.

Does the same problem affect calendar and survey embeds?

Yes, because they use the same mechanism. A calendar is a cross-origin document whose height changes as the visitor moves between months or picks a slot, so it depends on the same message-and-resize handshake and fails in the same ways.

We build your GoHighLevel account for you

CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.

  • Setup (one-time)$850
  • Ongoing (per month)$38.80
Get my free setup quote

No obligation quote · reply within 1 business day

This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.

$850 setup, $38.80/mo ongoingGet a quote