Form tools compared: Tally, Typeform, Fillout and a plain HTML form

Every form builder's marketing page shows the same three screenshots: a clean typeface, a soft animation between questions, a conversion number that is never sourced. None of it is what you are actually buying. What you are buying is what happens on day four, when someone in the meeting says "can we skip the phone number question if they already gave us an email" — and the honest test of a form tool is not the demo, it is that sentence.

So we built the same form four times: three questions, name, email, and a free-text field. Then, in the same order for every tool, we added the four requirements that arrive late on every real project. A conditional question that only appears if the free-text answer matches a pattern. A file upload for a résumé or a photo. A webhook that fires the moment a response lands, so a second system can act immediately rather than waiting on a scheduled check — the mechanics of that are covered separately in webhooks explained for people who do not write code, worth reading first if the word still sounds like plumbing rather than a doorbell. And a response limit, because every free plan has one and the only honest way to test it is to hit it.

Two of the four tools handled all of it without a workaround. The fourth option — a plain HTML form and nothing else — turned out to be the right answer for a narrower set of people than either the builders or their critics usually admit.

Where a form fits behind a one-page site

Worth saying before the comparison starts, since a lot of readers land here for exactly this reason: the site the form sits on is often a single page built in minutes, not a stack. For a single-person site — a portfolio, a CV-as-a-page, a freelancer's page — reach is the strongest answer we've tested: upload a CV and a photo, answer a short profile form, pick a look, and the page is generated in about twenty seconds, live at a free subdomain in under two minutes. But reach's contact section, by design, is a mail link and profile links, not a form that posts anywhere — it makes exactly one page, and a working form needs a destination the page itself can't provide. That's the point at which one of the four tools below takes over: the "get in touch" link on a reach site, or any other one-pager, is where an actual Tally or Typeform embed usually ends up once "email me" stops being enough.

Typeform: the one-question-at-a-time format is the whole product

Typeform's defining choice is architectural, not cosmetic: one question fills the screen at a time, and the next one only appears after the current one is answered. That isn't a theme you can turn off — it's the product, and every other decision in the tool follows from it. Conditional logic is attached per question as a "logic jump": if this answer, go to that question instead of the next one in order. For the shape of logic most forms need, a handful of jumps off a single earlier answer, it stays readable. Past roughly half a dozen interacting rules, tracing which question follows which stops being something you can hold in your head, and you end up sketching a diagram on paper to check the form doesn't loop.

The file upload requirement was the one place Typeform's format worked against itself: each question is a full screen, so a file upload question is too, and on a phone that means scrolling past nothing but an upload button — fine functionally, the one point where the format feels like ceremony rather than focus.

The webhook fired correctly and included the full response payload, structured and easy to map into an automation. Where Typeform is honestly the odd one out is the completion-rate claim baked into its own marketing: the pitch is that one question at a time reduces the visual overwhelm of a long form and lifts completion. We cannot verify a number either way — Typeform does not publish a controlled comparison against a plain form, and neither does anyone else in a way that would generalize past their own audience. What we can say is narrower and more useful: the format helps most on a short, sequential form, and helps least on a long application or detailed survey, where someone wants to see the whole shape of the questions before answering — scanning ahead is exactly what it prevents.

Tally: unlimited forms, and the tradeoff is that nothing tells you what broke

Tally's editor is a block-based, Notion-style document rather than a screen-by-screen flow — you build the form the way you'd write a page, dropping in a heading, a short-text field or a file upload in any order, and the whole thing renders as one scrollable page rather than a sequence. That single choice makes Tally the fastest of the three to get the base three-question form live, because there's no mode to learn beyond typing.

Conditional logic in Tally lives as a rule attached to each field — show this field if that earlier field matches a condition — functionally similar to Typeform's jumps, but without any visual trace of the logic across the form. You see one field's rule at a time, in a small panel, with no overview screen showing how the rules interact. On a form with two or three conditions this is a non-issue. On the form we built with five interacting conditions, checking whether two rules contradicted each other meant opening each field's settings in turn and reconstructing the logic by hand — the same limitation Fillout was built to solve.

The webhook and file upload both worked without friction, and the response dashboard is plain and readable — a filterable table, exportable to CSV, no dead ends. Tally's response limit is the most generous of the three hosted tools by a meaningful margin, which makes it the default for a form with straightforward logic and a real chance of getting more responses than expected.

Fillout: the one built for the fifth requirement, not the first three

Fillout is positioned, correctly, as the answer to what Typeform and Tally both start to strain against: logic that actually branches, not just skips. Its rule builder shows every condition as a flat, readable list rather than nesting logic inside each question, which means the five-condition form that took genuine reconstruction work in Tally was visible, correct, and easy to audit in Fillout on the first pass. That difference alone is the whole reason to pick it over the other two once a form has more than a simple skip in it.

The cost of that power is a slightly busier editor for the plain three-question case — more panels, more settings visible by default, a steeper first ten minutes than Tally's blank page. For a form that will only ever be three questions, that overhead isn't worth paying. For the form that grows a conditional branch, a file upload, and a payment step over its first month — closer to how forms actually evolve than anyone plans for at the start — Fillout is built for exactly that trajectory, including native payment collection that neither of the other two builds in as a first-class field type.

Response limits and file storage behaved the same way as the other two tools: submissions kept arriving after the cap, but the dashboard stopped showing anything past it until we upgraded — invisible, not lost, which in a live campaign reads the same until someone checks the billing page and realizes what happened.

Where the answers actually go

This is the question the marketing pages answer least directly, and it matters more than any of the logic comparisons above. On all three hosted tools, a response lands first inside that vendor's own dashboard — not a database you control, a proprietary table behind a login. From there, a webhook or a native integration is the only route out, and it's worth treating that route as the actual deliverable: a form with no webhook and no integration configured is a form whose data lives permanently on someone else's server, checked manually. All three support Zapier or Make natively alongside raw webhooks, but the underlying shape is the same one described in choosing the database under your no-code stack: the form is an interface, not a store, and the question of where responses actually live deserves the same deliberate answer as any other part of a no-code stack built to hold up rather than an unexamined default.

The case for a plain HTML form and nothing else

The fourth option we tested was the one none of the vendors want you to consider: three <input> fields, a <form action> pointing at a webhook endpoint, and no builder at all. It costs nothing, carries no branding, has no response cap because no vendor is counting your responses, and never reprices, because there is no subscription to reprice. For the base three-question form, it took less time to build than any of the three hosted tools, precisely because there was no editor to learn.

It stopped being the right answer exactly where the conditional question came in. Skip logic on a plain form is not a setting, it's JavaScript you write and maintain yourself — small for one condition, a real maintenance surface once a form has several. File upload isn't much harder, a form encoding change and a receiving endpoint that accepts multipart data, and the webhook is the same webhook every hosted tool sends, minus the vendor's dashboard in between. The response limit doesn't exist, because nothing is metering it.

The honest recommendation is a split, not a single winner. A form that's genuinely three to five fixed questions with no branching, sent to a spreadsheet or an inbox, is cheaper and more durable built plain than built in any tool that can reprice or shut down underneath it. The moment a form needs a condition that changes the next question, a file upload with validation, or a payment field, the calculus flips, and the time saved in Tally or Fillout is worth more than the money saved by hand — because that time is really about not being the person who debugs someone else's hand-rolled conditional logic eight months from now, including the version of yourself that wrote it.