Comparison

Keeping your own form, or building the receiver behind it.

A form on your own site needs something on the other end of the POST. There are three ways to get one: write the receiver yourself, embed a hosted form widget, or keep your own HTML and point it at an endpoint.

Short answer

The form markup is rarely the hard part. What costs time is everything after the submit: storing the payload, sending a notification that survives a mailbox outage, keeping spam out, handling a failed send, and answering "did this enquiry ever arrive?". FreelyForm is the last of the three options below — your HTML, your field names, our receiver — so the work is limited to one URL change.

The three options

Write the receiver yourself. A serverless function or a route on your own server accepts the POST, writes it somewhere durable, and calls a mail provider. Total control, and every failure mode is yours to design and to notice.
Embed a hosted form widget. The provider supplies the visible form as well: you drop in an iframe or a script and style it through their theme settings. Fastest route when nobody writes markup, slowest to make look like the rest of your site.
Keep your own form and add an endpoint. The markup, the styling and the fields stay in your repository; one action attribute points at a receiver you do not run.

Side by side

The middle column describes the category, not one vendor: widget builders differ, and the hedged rows are the ones that vary most. The FreelyForm column is this product's implemented behaviour.
Question	Written by you	Embedded widget	FreelyForm
Whose markup renders the form?	Yours	Usually theirs, styled through a theme editor	Yours — we never render it
Works with JavaScript disabled?	Depends what you wrote	Usually no: the widget is script or iframe	Yes — a plain POST is the primary path
Who runs the receiver?	You	They do	We do
Where submissions are stored	Your database, your backups	Their platform, their export limits	Stored, with an unlimited archive and CSV export
Owner notification	Your SMTP and your domain reputation	Usually included	Included, with a delivery record per channel
Retry after a failed send	You build it	Varies	Attempts recorded, last error kept
Spam control	You build it	Usually included	Honeypot, heuristics, time trap, optional Turnstile per form
Server-side validation and routing	You build it	Often visual logic, evaluated in the widget	Require, block, spam and route rules run on the endpoint
File uploads	You handle storage, MIME checks and cleanup	Plan-dependent	5 files × 25 MB by default, extension allowlist, 90-day attachment retention
Draft and resume link	You build it	Uncommon	Send `_partial=1`, get a resume link back
Signed webhooks with replay	You build it	Uncommon	HMAC-SHA256, up to 5 attempts, delivery log, replay
API for reading submissions back	You build it	Usually read-only	Included: forms, submissions, CSV, deliveries, rules, webhooks
Time to a first delivered submission	Hours to days	Minutes	Minutes
Leaving with your data	It is already yours	Whatever the export allows	CSV and API on every tier, deletion on request
Who gets paged at 3am	You	Them	Us — with no published SLA yet
What it costs	Your host, your mail provider, your time	A subscription per seat or per form	Five published tiers; free is 80 submissions a month

Write it yourself if…

The payload must land in infrastructure you already run, with your own retention and access rules.
The form is one part of a larger server you are building anyway, so the receiver is genuinely a small addition.
You want no third party in the path, and you are prepared to own the failure modes that come with that.

Embed a form widget if…

Nobody on the team writes HTML, or the person who owns the form is not a developer.
The form needs conditional branching and you would rather build it in a visual editor than in code.
A slightly different look from the rest of the site is an acceptable trade for shipping today.

Keep your form and add an endpoint if…

The form already exists and matches your design — you want a receiver, not a redesign.
You need the submission stored, emailed, retried, filtered and exportable without maintaining any of it.
You want the delivery record: which channel was attempted, what failed, and a way to resend.
You want a server-side API for reading submissions back instead of another read-only export screen.

What the endpoint accepts

The contract is deliberately small, because everything else is your markup:

Any field names. 1–100 characters, up to 100 fields, values up to 10,000 characters. A repeated name becomes an array (checkbox groups, multi-selects).
Three body formats. application/x-www-form-urlencoded from a plain HTML form, multipart/form-data when files are attached, or JSON from your own script.
Reserved control fields. _replyto, _subject, _redirect, _gotcha, _ts, _partial, _resume, _idempotency. They shape the delivery, and they never appear as submission fields.
Two response shapes. HTML for a browser post (success page or your redirect), JSON for Accept: application/json so your own UI can render the outcome.

Moving to it, and back out

Create the form, then confirm every recipient inbox — notifications wait until an address is confirmed.
Keep the current field names for the first test; rename nothing yet.
Point a staging copy of the page at the endpoint.
Send four submissions: a normal one, one with a required field missing, one with a file, one that looks like spam.
Check the owner email, the autoresponse, and the webhook delivery records against what you expected.
Switch production traffic. The old receiver stays where it is, so rolling back is the same one-line edit in reverse.

What we will not claim

We publish no uptime percentage, no deliverability guarantee, and no customer numbers. Deliverability depends on your domain reputation and your recipients; reliability is backed by retries and a visible delivery record, not by a figure on a marketing page. There is no published SLA yet, and that is a real limitation if the form is business-critical.

Every submission is stored first, then delivered per channel. Nothing is lost when an inbox bounces.

Questions about the choice

Do I have to rebuild my form to use FreelyForm?

No. A standard HTML form keeps its markup and its field names; the <code>action</code> attribute changes to the endpoint. Forms that post through JavaScript keep their own code and send the same values to the same URL.

What does the embed script add on top of a plain HTML post?

One script tag catches the submit, posts the same values, and writes the result into the page instead of navigating away. Without it the endpoint answers with a full page — your success message or your redirect. Both paths hit the same endpoint with the same fields.

Can I define my own fields and field names?

Yes, and that is the whole model: there is no form builder to fight with. Names are yours (1–100 characters), a submission may carry up to 100 fields, and repeating a name turns it into an array, so checkbox groups and multi-selects arrive intact. Names beginning with an underscore are reserved for endpoint controls such as <code>_redirect</code> and <code>_replyto</code>.

When is a drag-and-drop embedded form the better choice?

When nobody on the team writes HTML, when the form needs a visual logic builder, or when it has to stand alone with no site behind it. A hosted form builder is the shorter path there, and FreelyForm is not a substitute for it.

What do I have to keep running if I write the receiver myself?

A host that accepts POST requests, somewhere durable to put the payload, a mail path with SPF and DKIM so notifications actually land, spam handling, retries for failed sends, and a person who notices when any of that stops working. That list is the work this endpoint removes.

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

Create your first form Read the quickstart

One action attribute · urlencoded, JSON, or multipart · no SDK, no build step