Skip to main content
All guides

Native embeds

How to embed a form without an iframe

Use real form controls inside your app instead of sending customers into a framed page that does not quite fit.

7 min readUpdated 2026-06-22For teams whose forms need to feel like part of the app.

Short answer

To embed a form without an iframe, use a form renderer that mounts real form controls in your app. The form should live in your DOM, inherit your layout and CSS, and still submit to a backend that handles validation, responses, files, and delivery.

Iframes are fine for quick hosted forms, but they can feel detached inside a product.

A native embed gives you better control over layout, customer context, analytics, and mobile behavior.

Do not replace an iframe with a bare form unless you also have a plan for responses, files, and edits.

01

Why teams move away from iframe forms

An iframe is easy to ship because the form provider owns the whole screen inside the frame. That same shortcut is the problem when the form belongs inside your product.

The frame has its own layout rules. Styling is limited. Height can be awkward. Passing logged-in customer context takes extra work. Analytics often split between the app and the form provider.

  • The form can look and feel separate from the product.
  • Mobile sizing and scroll behavior can be rough.
  • The app has less control over fields, focus states, and analytics.
  • The user may notice a different domain, style, or loading pattern.

02

What a native embed does differently

A native embed renders normal controls inside your page. The form sits beside the rest of your product UI. It can use your spacing, typography, buttons, account data, and route context.

This matters most for forms that are part of a workflow. A cancellation form, onboarding step, support intake, or file request should feel like the same app, not a pasted-in survey.

Area

Styling

Iframe form

Controlled mostly by the form vendor

Native form embed

Controlled by your app

Area

Context

Iframe form

Often passed through URL params

Native form embed

Can use app state and customer data

Area

Layout

Iframe form

Frame sizing and scroll behavior to manage

Native form embed

Part of the page layout

Area

After submit

Iframe form

Usually vendor-owned flow

Native form embed

Can trigger product actions directly

03

What to check before replacing an iframe

The form still needs a backend. If you build only the frontend, you still need validation, spam protection, file uploads, storage, exports, retries, notifications, and a way for your team to see the answers.

The best replacement keeps the native product feel without turning form operations into another internal system.

  • Can the form render real inputs in your app?
  • Can your team edit the form later without a deploy?
  • Can you pass safe customer context into hidden fields?
  • Are files attached to the response record?
  • Can responses move to CSV, webhooks, or connected tools?

04

How Fillo handles native embeds

Fillo renders forms with SDK packages instead of an iframe. React teams can use @usefillo/react. Other web frontends can use @usefillo/dom.

The form can be built in the editor or defined in code. Either way, submissions land in Fillo with the form version, source, answers, files, and delivery state kept together.

Questions

Quick answers.

No. An iframe can be perfectly fine for a standalone survey or a quick marketing form. It becomes a problem when the form needs to feel like part of a logged-in product.

No. A renderer can provide default fields while still letting your app own the page and override components when needed.

Yes. That is the point of a good headless form setup: native UI in your app, managed responses in the form system.