# Fillo guides

Last updated: 2026-06-22
Canonical URL: https://fillo.so/guides

Agent-readable versions of the Fillo guide library. These pages explain when to use headless forms, native embeds, React form infrastructure, and file upload forms.

## Guide index

- What is a headless form?: https://fillo.so/guides/headless-forms
- How to embed a form without an iframe: https://fillo.so/guides/embedded-forms-without-iframes
- Choosing a React form builder for product teams: https://fillo.so/guides/react-form-builder-for-product-teams
- How to build file upload forms that do not trap your files: https://fillo.so/guides/file-upload-forms-to-drive-box-s3

---

# What is a headless form?

Last updated: 2026-06-22
Canonical URL: https://fillo.so/guides/headless-forms

Know when a form should live inside your product, what the form system should handle, and when a hosted link is still enough.

## Short answer

A headless form is a form where your app owns the screen, the layout, and the components, while a form service handles the form definition, validation, submissions, files, and response workflow. Visitors stay inside your product instead of going to a hosted form page or iframe.

## Key takeaways

- Use headless forms when the form is part of the product experience.
- Avoid them for quick one-off surveys where a hosted link is enough.
- Check what happens after submit: responses, files, exports, webhooks, and edits matter as much as fields.

## What headless means in practice

Headless means the form system does not force its own page or visual frame on your product. Your app renders the fields. Your CSS, layout, route, analytics, and account context stay in charge.

The form service still does useful work. It stores the form definition, validates answers, records responses, keeps versions readable, handles file uploads, and gives your team somewhere to review what came in.

- Your app controls the interface.
- The form service controls the form plumbing.
- The respondent should not feel like they left your product.


## When a headless form is the right fit

Headless forms are useful when the form sits in a real product flow. Think onboarding, cancellation feedback, customer intake, quote requests, job applications, account setup, or support forms that need files.

They are less useful when you only need a public survey link. In that case, a hosted form builder can be faster and good enough.

| Use case | Hosted form | Headless form |
| --- | --- | --- |
| Simple survey link | Usually fine | Often more setup than needed |
| In-app onboarding | Feels like a detour | Fits the product flow |
| Logged-in customer form | Harder to pass context | Can use account and route context |
| File-heavy intake | Often hits storage limits | Can connect to your storage setup |


## What to look for before choosing one

The renderer is only one part of the decision. A form becomes work after someone submits it. You need to know where responses go, how files are stored, whether old responses stay readable after edits, and who can change the form later.

If a tool only gives you a component but no response workspace, you may still end up building the admin table yourself.

- Native rendering, not an iframe wrapped in a component.
- Validation that runs from the same schema as the renderer.
- A response grid your team can use without engineering help.
- File upload handling that fits your storage and privacy needs.
- A way to edit live forms without redeploying every copy change.


## How Fillo approaches headless forms

Fillo is built for product teams that want forms inside their own app. You can define a form in code with the SDK or build it in the editor, then render it as real controls in React or another web frontend.

Fillo keeps the schema, responses, files, exports, webhooks, and form versions together. The goal is not just to show fields. The goal is to stop forms becoming another small internal product you have to maintain.

## FAQ

### Is a headless form the same as an embedded form?

Not always. Many embedded forms are still iframes. A headless form renders through your app, so the fields are part of your DOM and can use your layout and components.

### Do headless forms need developers?

Usually for the first install, yes. After that, the right setup lets non-developers edit labels, choices, required fields, and destinations without a deploy.

### Can a headless form still have a visual editor?

Yes. Headless describes how the form renders. The form can still be managed in a visual editor behind the scenes.

## Related

- Editor and code: https://fillo.so/features/builder-and-code
- Install Fillo: https://fillo.so/docs/embed
- Embedded forms without iframes: https://fillo.so/guides/embedded-forms-without-iframes

# How to embed a form without an iframe

Last updated: 2026-06-22
Canonical URL: https://fillo.so/guides/embedded-forms-without-iframes

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

## 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.

## Key takeaways

- 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.

## 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.


## 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 | Iframe form | Native form embed |
| --- | --- | --- |
| Styling | Controlled mostly by the form vendor | Controlled by your app |
| Context | Often passed through URL params | Can use app state and customer data |
| Layout | Frame sizing and scroll behavior to manage | Part of the page layout |
| After submit | Usually vendor-owned flow | Can trigger product actions directly |


## 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?


## 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.

## FAQ

### Are iframes bad for every form?

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.

### Does native rendering mean I have to build every field?

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

### Can a native embed still collect responses in a form tool?

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

## Related

- Framework support: https://fillo.so/features/frameworks
- Embed docs: https://fillo.so/docs/embed
- What is a headless form?: https://fillo.so/guides/headless-forms

# Choosing a React form builder for product teams

Last updated: 2026-06-22
Canonical URL: https://fillo.so/guides/react-form-builder-for-product-teams

Pick a setup that gives developers native React rendering and gives the team a safe way to edit forms and review responses.

## Short answer

A React form builder for product teams should do more than render inputs. It should let developers place the form inside the app, let teammates change the form after launch, and keep submissions, files, validation, versions, exports, and webhooks in one reliable flow.

## Key takeaways

- React form libraries are good for building UI, but they do not usually solve response operations.
- Hosted builders are easy to edit, but they often push users into an iframe or hosted page.
- Product teams usually need both: native React rendering and a workspace for edits and responses.

## The usual split is the problem

Developers often reach for a React form library when they need control. That works until the form needs file uploads, exports, notifications, version history, or a response view for the team.

Non-developers reach for a hosted builder because it is editable. That works until the form needs to sit inside a real product flow and match the app.

| Choice | What it gives you | What is usually missing |
| --- | --- | --- |
| React form library | Control over UI and state | Editor, responses, uploads, exports |
| Hosted form builder | Fast editing and response collection | Native product UI |
| Headless form builder | Native UI plus managed form operations | Initial SDK install |


## What product teams should require

A product form is not just a contact form. It may use account data, show inside settings, collect sensitive files, drive support workflows, or change after customers start using it.

Before choosing a tool, write down who owns each part: the screen, the schema, the edits, the responses, the files, and the handoff to the next system.

- React-native rendering with accessible HTML controls.
- A schema that can be reviewed and reused.
- A visual editor for safe post-launch changes.
- Custom field support for product-specific UI.
- A response workspace that non-developers can use.
- Exports and webhooks for the systems around the form.


## A healthy workflow

The first version often belongs in code because it sits beside a product feature. Later changes often belong with the people who run the workflow.

That is the balance to aim for. Developers should not redeploy the app for every copy change. Teams should not be able to break a product flow by editing a form in a disconnected tool.

- Developers add the renderer to the route, modal, or onboarding step.
- The form definition is created in code or in the editor.
- The team tests the flow and publishes it.
- Later changes happen in the form system while the app keeps the same integration.


## How Fillo fits React teams

Fillo gives React teams a renderer, an editor, and a response workspace. You can render a published form by ID, or define a form in code with `defineForm` when the form belongs beside a feature.

The same schema drives rendering, validation, responses, and exports. That keeps the form from splitting into frontend logic, backend validation, and a separate admin table.

## FAQ

### Is Fillo a replacement for React Hook Form?

Not exactly. React Hook Form is a library for managing form state in React. Fillo is a form infrastructure layer: renderer, schema, editor, responses, uploads, exports, and webhooks.

### Can I use custom React components?

Yes. Fillo can render default controls, and React teams can override components when a field needs product-specific UI.

### Can product or ops edit the form later?

Yes. The point is to keep the app integration stable while the form content, choices, required fields, and destinations can change in Fillo.

## Related

- Builder and code: https://fillo.so/features/builder-and-code
- Code-first example: https://fillo.so/examples/code-first
- React install docs: https://fillo.so/docs/embed

# How to build file upload forms that do not trap your files

Last updated: 2026-06-22
Canonical URL: https://fillo.so/guides/file-upload-forms-to-drive-box-s3

Collect documents, screenshots, CVs, and customer evidence without separating the upload from the response that explains it.

## Short answer

A good file upload form should collect the answer and the file together, send the file to storage you control, and keep a clear record of who submitted it, which form version they saw, and where the file went.

## Key takeaways

- File upload forms need storage decisions, not just a file input.
- Files should stay connected to the response that explains them.
- Your team needs a clear review and export path after the upload finishes.

## Why file upload forms get messy

The field looks simple. The work around it is not. You need upload limits, progress, retries, storage destinations, permissions, metadata, response links, and a way for the team to review what arrived.

If uploads and answers land in different places, the follow-up becomes slow. Someone has to match a file in storage with the person who submitted the form.

- A CV without the application answers is hard to review.
- A screenshot without browser or account context is easy to misread.
- A document in storage without a response record is just a loose file.


## Decide where files should live

For product and customer workflows, the safest default is to put files in storage your team controls. That might be Google Drive, Box, or an S3-compatible bucket, depending on how your company handles documents.

The form tool should keep the response metadata and file reference. It should not make your team download files from a vendor table and manually move them later.

| Storage choice | Good for | Watch out for |
| --- | --- | --- |
| Google Drive | Teams that already review files in Drive | Folder structure and access rules |
| Box | Teams with document workflows in Box | Permissions and naming conventions |
| S3-compatible storage | Product teams that own storage infrastructure | Lifecycle rules and access policies |
| Form vendor storage | Very simple forms | Data ownership and export friction |


## Keep files attached to the response

The response record should show the answers, source, timestamps, form version, and file references together. That is what lets someone review the submission without hunting across tools.

This matters for job applications, vendor onboarding, customer support, insurance intake, grant applications, security questionnaires, and any flow where the file is evidence for the answers.

- Show file names and storage destination in the response.
- Keep the form version so old responses still make sense after edits.
- Export response data without losing the file reference.
- Use webhooks when another system needs to act on the submission.


## How Fillo handles upload forms

Fillo lets you add file upload fields to forms that render inside your app. Uploaded files can go to connected storage such as Drive, Box, or S3-compatible storage while the response keeps the file reference and metadata.

That means the app can keep a native form experience, and the team still gets a response workspace for review, exports, and handoff.

## FAQ

### Should files live in the form tool or my own storage?

For product workflows, your own storage is usually better. It keeps files closer to your access rules, retention policies, and existing review process.

### Can a file upload form still render inside my app?

Yes. The upload field can be part of a native form renderer while the upload itself goes through the storage flow configured for the form.

### What should a response record include for uploads?

At minimum: answers, file names, storage references, submit time, source, and the form version the respondent saw.

## Related

- Responses and uploads: https://fillo.so/features/responses-and-uploads
- Job application example: https://fillo.so/examples/job-application
- Headless forms: https://fillo.so/guides/headless-forms