You have written the form. The markup is exactly how you want it, the styling matches the rest of the page, and then you reach the action attribute and realise there is nothing to put in it.
This is the most common problem on the modern web and it has nothing to do with forms being hard. It is that static sites, JAMstack frameworks, site builders and AI-generated apps all ship a frontend with no server behind it, and a plain HTML form needs somewhere to POST.
Why a mailto link does not work
The first thing everybody tries is pointing the form at a mailto address. It appears to be exactly the feature you want, and it fails for several reasons at once.
It opens the visitor's mail client rather than sending anything, which means it does nothing at all on a machine with no mail client configured, which is most of them. The message arrives as an unreadable encoded blob. Nothing is recorded if they close the window. And it publishes your address in the page source for every scraper on the internet.
It is not a broken feature so much as a feature from a different era. Treat it as unavailable.
The four real options
Everything that actually works is one of these, and the right answer depends on what you already have.
- Write a backend endpoint. A small serverless function that receives the POST and sends mail through an email API. Full control, and now you own deliverability, spam, retries and file storage.
- Use a form backend. Point the form at a URL somebody else runs. You keep your HTML exactly as written and they handle the rest.
- Use a form builder. Do not write the form at all; build it in a tool and embed it. You give up control of the markup and get logic, payments and a dashboard.
- Use your site builder's own form. Fine if you are on a platform that has one, and the reason people leave those platforms when they outgrow it.
When a form backend is the right answer
If you already have the form and only need somewhere for it to go, a form backend is the smallest possible solution. You change one attribute and you are finished.
FormSubmit is the clearest example of this shape. You point your existing form at an endpoint, and it emails you every submission, blocks spam, stores uploaded files and forwards the data to webhooks, Slack, Discord or Google Sheets. There is no server code, no SMTP account and no plugin, and your markup is untouched.
That last part is the whole argument. If you have spent a day getting a form to look right inside your design system, a solution that asks you to replace it with an iframe is not a solution. Keeping the HTML yours is worth more than most feature comparisons admit.
If you already have the form and only need somewhere for it to go, changing one attribute is the whole job.
When a form builder is the right answer
The moment the form stops being a form, a backend stops being enough.
If questions need to appear based on earlier answers, if there is a total to calculate, if you need to take a payment or hold an appointment slot, if somebody non-technical has to change the wording next week, then you want the logic and the interface rather than a POST target. That is a different product and it is worth knowing which one you are shopping for.
The honest test: are you writing the form yourself in HTML, or would you rather not write it at all? Those two answers lead to different tools and neither is a compromise.
What a form backend has to get right
If you go that way, these are the things that separate one that works from one that quietly loses submissions.
- Deliverability. Messages have to arrive and not land in spam. This is the single hardest part and the main reason not to build it yourself.
- Spam filtering. A public endpoint attracts bots within days. A honeypot field plus a modern challenge stops almost everything without a captcha anybody has to read.
- File uploads. Phone photographs are routinely 5 to 12 MB. A backend that caps at 2 MB is one half your visitors cannot use.
- Retries. If the integration on the other end is down, the submission has to wait rather than disappear.
- What happens at the limit. Some providers discard submissions over a plan's quota. Others hold them. The difference matters a great deal on the month you find out.
- Where the data sits. Whether addresses are hashed, whether uploads are private, and whether you can choose not to store anything at all.
The redirect after submit
With a plain HTML form and no JavaScript, the browser navigates on submit, so the visitor lands wherever the backend sends them. Point that at a thank-you page on your own site rather than a hosted one.
It is a small thing that does a lot of work. The visitor stays on your domain, you can say what happens next in your own words, and you get a page you can measure as a conversion. A hosted confirmation page is a hand-off at the exact moment somebody has committed.
A short decision rule
Three questions, in order.
Do you already have the form written? If yes, and it does nothing conditional, a form backend is the answer and you are done in two minutes. If no, a builder will be faster than writing one.
Does it need to think? Branching, calculations, payments, bookings, scoring. Any of those and you want a builder, because reimplementing them on top of a POST endpoint is how a weekend disappears.
Who edits it next? If the answer is somebody who does not write HTML, the form has to live somewhere they can reach. That decides it regardless of the other two.