# Fillo
> Forms inside your product, with your UI. Fillo renders native fields in the host app while handling validation, conditional logic, file uploads, responses, exports, webhooks, and safe post-launch edits. It is not an iframe or hosted-page detour.
## Start here
- Full agent reference: https://fillo.so/llms-full.txt
- Install docs as Markdown: https://fillo.so/docs/embed.md
- Human install docs: https://fillo.so/docs/embed
- Guides as Markdown: https://fillo.so/guides.md
- Features as Markdown: https://fillo.so/features.md
- Pricing as Markdown: https://fillo.so/pricing.md
## Package choice
- React or Next.js: install `@usefillo/react@latest` and render ``.
- Vue, Svelte, Astro, web components, plain browser JavaScript, or any other frontend: install `@usefillo/dom@latest` and call `renderForm()`.
- If Fillo is already installed, upgrade the matching package to `@latest` and update the lockfile.
## Minimal React install
```tsx
import { FilloForm } from "@usefillo/react";
import "@usefillo/react/styles.css";
export function Feedback() {
return ;
}
```
## Minimal DOM install
```ts
import { renderForm } from "@usefillo/dom";
import "@usefillo/dom/styles.css";
renderForm(document.querySelector("#fillo-form"), {
formId: "FORM_ID_OR_SLUG",
});
```
## Key implementation rules
- Keep the form inside the product UI. Do not use an iframe.
- Import the default Fillo stylesheet unless the app already has intentional form styling.
- Pass `theme={{ colorScheme: "dark" }}` when rendering on a known dark surface.
- Pass a `client` when a code-defined form should collect responses.
- Never call `provisionWorkspace()` during render. Run provisioning once, save the `pk_` publishable key to public env, and read it from there.
- Use `onSubmitted(id, data)` for app-side follow-up behavior after Fillo records the response.
- Use webhooks when another backend needs the submission.
## Current docs freshness
- Agent docs: 2026-06-22
- Guides: 2026-06-22
- Pricing: June 21, 2026
---
# Fillo install reference
Last updated: 2026-06-22
Canonical human page: https://fillo.so/docs/embed
Agent entrypoint: https://fillo.so/llms.txt
## Short answer
Fillo renders forms as native controls inside the host app, not as an iframe or hosted-page detour. Use `@usefillo/react` in React or Next.js apps. Use `@usefillo/dom` for Vue, Svelte, Astro, web components, plain browser JavaScript, or any other frontend. Fillo handles validation, conditional logic, file uploads, responses, CSV export, webhooks, and later edits.
## Choose the package
| App surface | Package | Primary API |
| --- | --- | --- |
| React or Next.js | @usefillo/react | |
| Custom React layout | @usefillo/react | , , useFillo(), useField() |
| Vue, Svelte, Astro, vanilla browser JavaScript | @usefillo/dom | renderForm() |
| No build step | @usefillo/dom | standalone.global.js or the web component |
## Install for React or Next.js
```bash
npm install @usefillo/react@latest
```
```tsx
import { FilloForm } from "@usefillo/react";
import "@usefillo/react/styles.css";
export function Feedback() {
return ;
}
```
Published forms can be rendered by form id or slug. Draft forms are not served by the public API.
## Create a new form from code
Use `defineForm` for code-owned forms. Always pass a `client` if the form should collect responses.
```tsx
import { FilloForm, createClient, defineForm } from "@usefillo/react";
import "@usefillo/react/styles.css";
const client = createClient({ key: process.env.NEXT_PUBLIC_FILLO_KEY! });
const feedback = defineForm({
id: "product-feedback",
title: "Product feedback",
pages: [{ id: "p1", blocks: [
{ id: "email", kind: "email", label: "Work email", required: true },
{ id: "score", kind: "linear_scale", label: "How was this?", min: 0, max: 10 },
{ id: "notes", kind: "long_text", label: "What should we know?" },
]}],
});
export function ProductFeedback() {
return ;
}
```
## Create a live workspace with the CLI
Use this path when the app does not have a Fillo workspace yet. The CLI can create a capped preview workspace, push the form live, and print the form id plus a claim URL.
```bash
npx @usefillo/cli@latest init
npx @usefillo/cli@latest push waitlist.json --handle beta-waitlist
```
If the developer already has a Fillo account, use `npx @usefillo/cli@latest login` instead of `init`.
## Install for other frameworks
```bash
npm install @usefillo/dom@latest
```
```ts
import { createClient, defineForm, renderForm } from "@usefillo/dom";
import "@usefillo/dom/styles.css";
const client = createClient({ key: "pk_your_key" });
const form = defineForm({
id: "contact",
title: "Contact",
pages: [{ id: "p1", blocks: [
{ id: "email", kind: "email", label: "Email", required: true },
{ id: "message", kind: "long_text", label: "Message" },
]}],
});
const instance = renderForm(document.querySelector("#fillo-form"), {
form,
client,
onSubmitted: (id, data) => console.log("response", id, data),
});
// instance.setValue("email", "jane@example.com");
// await instance.submit();
// instance.destroy();
```
## No build step
```html
```
## Responses and files
- With a `client`, responses post to Fillo and appear in the dashboard.
- `onSubmitted(id, data)` runs app-side follow-up code after Fillo records the response.
- Use webhooks to deliver responses to another backend.
- File uploads can go to connected storage such as Google Drive, Box, or S3-compatible storage while the response keeps the file reference.
- Without a `client`, a code-defined form is render-only and will not save responses.
## Styling
- Import the default stylesheet unless the app already has intentional form styling.
- Use the `theme` prop for quick tokens: `{ colorScheme, primary, background, text, radius, fontFamily }`.
- Use `theme={{ colorScheme: "dark" }}` when the form renders on a known dark surface or the host app uses class-based dark mode.
- Write CSS or Tailwind against `.fillo-*` classes. The SDK default CSS is in a lower cascade layer, so host app rules win.
- Each field has `data-field`; each choice row has `data-option`.
## Auto-submit feedback forms
For one-tap article feedback, CSAT, or inline pulse checks, set `settings.submitMode` to `"auto"`. The default renderer hides the submit button for complete discrete answers, then brings it back when the answer opens a text, upload, or custom follow-up. Add `submissionLimit: "once_per_visitor"` for browser-scoped one-response feedback.
```tsx
const articleVote = defineForm({
id: "article-vote",
title: "Was this helpful?",
pages: [{ id: "p1", blocks: [
{ id: "vote", kind: "select", label: "Was this helpful?", required: true,
options: [
{ id: "up", label: "Yes", icon: "thumbs_up" },
{ id: "down", label: "No", icon: "thumbs_down" },
] },
{ id: "unclear", kind: "long_text", label: "What was unclear?",
visibleIf: [{ fieldId: "vote", op: "eq", value: "down" }] },
]}],
settings: { submitMode: "auto", submissionLimit: "once_per_visitor" },
});
;
```
## Headless layout control
Use `` when the app must own the whole layout. It runs the form engine but renders no default layout. Place fields with ``, render custom markup between fields, and drive page state or submit with `useFillo()`.
```tsx
import { FilloProvider, FormField, useFillo } from "@usefillo/react";
;
function SubmitButton() {
const form = useFillo();
return ;
}
```
## Field kinds
Field kinds: short_text, long_text, email, url, phone, number, select, multi_select, dropdown, checkbox, rating, linear_scale, ranking, matrix, signature, date, file_upload, hidden, custom.
Content blocks: heading, paragraph, divider.
---
# Pricing - Fillo
Last updated: June 21, 2026
Fillo is free during early access. The launch plans below are shown so teams can compare limits before they build around the product.
## Free
- Price: €0/month or $0/month
- Best for: building and shipping your first forms
- Limits: 200 completed responses per month at launch; Versioned response history
- Includes: Unlimited forms; Editor plus code install; 200 responses / month at launch; File uploads to Drive, S3/R2, or Box; Signed webhooks and CSV export; Sheets, Notion, and Zapier; Versioned response history
## Everything
- Price: €35/month or $39/month
- Best for: forms your product depends on
- Limits: 5,000 completed responses per month, then overage; Priority email support
- Includes: Everything in Free, plus; 5,000 responses / month, then overage; Insights and analytics; Draft with AI; Headless custom layouts; Respondent auto-receipts; Priority email support
## Notes
- No card is required to start.
- A response is one completed form submission.
- Form previews, edits, and partial entries do not count as responses.
- Uploaded files go to the storage provider you connect, such as Google Drive, Box, or an S3-compatible bucket. Fillo keeps the response record and file reference.
- Signed webhooks and CSV export are available on every plan.
- A small "Powered by Fillo" badge shows on rendered forms on every plan, including paid; upgrading does not remove it. Headless embedding (no Fillo layout) carries no badge and is a paid capability.
- Custom domains for hosted forms are planned and marked as soon.
## Useful links
- Human pricing page: https://fillo.so/pricing
- Install docs: https://fillo.so/docs/embed
- Agent reference: https://fillo.so/llms.txt
---
# 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
---
# Fillo features
Last updated: 2026-06-22
Canonical URL: https://fillo.so/features
Fillo is form infrastructure for products that need native form rendering, editable form definitions, uploads, responses, exports, and webhooks.
## Feature index
- Let the form change without a deploy: https://fillo.so/features/builder-and-code
- Review answers and files without building an admin table: https://fillo.so/features/responses-and-uploads
- Render the same form in any web frontend: https://fillo.so/features/frameworks
---
# Let the form change without a deploy
Canonical URL: https://fillo.so/features/builder-and-code
Add the form to your app once. Fillo keeps the editor, schema, validation, responses, uploads, and published versions in one place.
Proof point: Editor changes and code-defined forms use the same schema.
## What it provides
- Edit without shipping: Change labels, choices, close dates, storage, and webhooks from Fillo.
- Keep important forms in code: Use defineForm when a form belongs beside the feature that uses it.
- One response pipeline: Editor-built and code-defined forms submit to the same response grid.
## Build it where it belongs. Edit it where it changes.
Product forms usually start in code, then change through support, sales, operations, and customer feedback. Fillo keeps those later changes out of deploy cycles.
- Create the first version: Start in the editor, paste a setup prompt into your coding agent, or define the form with defineForm.
- Render it natively: Drop the form into your route, modal, settings page, or onboarding step. It renders in your DOM, not an iframe.
- Let the team adjust it: Update questions, required fields, destinations, and publish settings without asking engineering for another release.
## What changes after install
The app still owns the product experience. Fillo owns the form work that tends to become maintenance.
| Area | If you build it yourself | With Fillo |
| --- | --- | --- |
| Editing | Every label, option, and required field change needs app work. | The team can edit the live form setup in Fillo. |
| Schema | Validation logic drifts between frontend, API, exports, and admin screens. | The same schema drives rendering, validation, responses, and exports. |
| Versions | Old submissions become hard to read after the form changes. | Responses stay tied to the form version the respondent saw. |
## FAQ
### Can I use only the visual editor?
Yes. You can build and publish a form from the editor without defining it in code. The SDK is only needed when you want the form inside your app.
### Can developers keep forms in code?
Yes. Code-defined forms use the same schema and response flow, so product-owned forms can live beside the feature that uses them.
### Does the form render inside my app?
Yes. Fillo renders normal HTML controls inside your product. You are not sending visitors into a separate iframe flow.
# Review answers and files without building an admin table
Canonical URL: https://fillo.so/features/responses-and-uploads
Collect the submission, keep files attached, see where it came from, and send it to the next tool without writing another back-office screen.
Proof point: Answers, files, source, and delivery state stay together.
## What it provides
- Read the whole response: Answers, source page, timestamps, and delivery state are shown together.
- Keep uploads attached: Large files go to connected storage while the response keeps the reference.
- Move data when needed: Export CSV, send webhooks, or connect the tools that need the submission.
## The work starts after submit.
Most forms need review, handoff, and file handling. Fillo gives your team that operational layer before you build a custom dashboard.
- Collect the response: Fillo records the answers, form version, source route, and respondent metadata that you choose to send.
- Attach the files: Uploads go to Drive, Box, or S3-compatible storage while staying attached to the response record.
- Hand it off: Review in Fillo, export to CSV, or push the submission through webhooks and connected tools.
## What you avoid building
A response grid looks simple until it needs files, exports, retries, and history. That is the layer Fillo provides.
| Area | Custom admin table | Fillo response workspace |
| --- | --- | --- |
| Files | Answers and uploads often end up in separate systems. | Files stay attached to the response record. |
| Review | You design filters, detail views, empty states, exports, and permissions. | Your team can inspect responses immediately. |
| Delivery | Webhook failures and export requests become one-off support work. | Delivery state, CSV export, and signed webhooks are built in. |
## FAQ
### Where do uploaded files go?
Files upload to the storage provider you connect, such as Google Drive, Box, or an S3-compatible bucket. Fillo keeps the response link and metadata.
### Can I export responses?
Yes. You can export responses to CSV whenever another person, spreadsheet, or system needs the data.
### Do I need to build my own response dashboard?
No, not to start. Fillo gives your team a response grid and detail view, and you can still pull data through the API or webhooks later.
# Render the same form in any web frontend
Canonical URL: https://fillo.so/features/frameworks
Use React, Vue, Svelte, Astro, a web component, or plain browser JavaScript. The form, validation, uploads, and responses stay the same.
Proof point: One form definition. Multiple renderers.
## What it provides
- React first-class: Install @usefillo/react and render with the FilloForm component.
- Other web frontends: Use @usefillo/dom in Vue, Svelte, Astro, or framework-managed pages.
- Plain HTML works: Use the standalone bundle or web component when there is no build step.
## Choose the renderer. Keep the form system unchanged.
Fillo is not a React-only widget. The frontend package changes by project, but the published form and response pipeline stay consistent.
- Pick the package: Use @usefillo/react for React apps or @usefillo/dom for other browser frontends.
- Mount the form: Render into the part of your product where the form belongs, with your layout around it.
- Reuse the same setup: The same form can appear in a product route, docs page, customer portal, or plain HTML page.
## What stays consistent across frameworks
The renderer is local to your frontend. The form definition, validation, uploads, and responses are shared.
| Area | Frontend concern | Shared Fillo concern |
| --- | --- | --- |
| Placement | React page, Astro site, Svelte app, or plain HTML. | Same form id and published schema. |
| Styling | Your CSS, layout, fonts, and product context. | Optional default styles and override-friendly markup. |
| Data | Account ids, source route, and after-submit behavior. | Validation, uploads, responses, exports, and webhooks. |
## FAQ
### Is Fillo React-only?
No. React has the first-class package, and @usefillo/dom covers Vue, Svelte, Astro, web components, and plain browser JavaScript.
### Do I have to use an iframe?
No. Fillo renders native controls in your page, so the form can inherit your layout, fonts, focus styles, and product context.
### Can the same form render in different frontends?
Yes. The form definition, validation, responses, and upload flow are shared. You choose the renderer that fits each frontend.