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