1. What is a form backend
A form backendis the server-side endpoint that receives an HTML form's submission, validates it, screens it for spam, stores it, and forwards a copy somewhere useful — your inbox, a Slack channel, a Notion database, or a CRM. It is, in practice, the boring plumbing that turns the data a user types into a contact form into something you can actually read and act on.
Picture it as a three-box diagram. On the left is the browser: a rendered HTML form with a Name field, an Email field, and a Message textarea. In the middle is the form backend: an HTTPS endpoint at a domain like splitforms.com/api/submit that accepts a POST request, runs validation and spam checks, writes a row to a database, and triggers email and webhook fan-out. On the right is your destinations: your inbox, your webhook receiver, a CSV export, a dashboard. The form backend is the middle box. That's the entire concept.
Before hosted form backends existed you had two options. You ran a PHP server with mail()and your hosting company's SMTP relay, or you wrote a serverless function (Lambda, Vercel, Cloudflare Workers) that did the same thing in JavaScript. Both work, both involve credential management, SPF records, spam filtering, and a dashboard you'd eventually have to build. A hosted form backend is the "don't build that yourself" option. It's the form equivalent of using Stripe instead of writing your own card processor.
The market has names for many adjacent things — form-to-email service, contact form API, form submission service, headless form service — and they all refer, roughly, to the same product category. This guide uses "form backend" throughout because that's the term developers actually search for.
2. Why static sites need a form backend
A static site has no runtime. The HTML, CSS, and JavaScript are pre-built at deploy time and served from a CDN — there is no server process listening for POSTs, no database, no SMTP client. That's the whole point of static. It's fast, cheap, and hard to attack because there's nothing live to attack. The tradeoff is that anything that requires server work — and a form submission requires server work — has to live somewhere else.
JAMstack frameworks like Next.js, Astro, Hugo, Eleventy, and React-on-static-export inherit this constraint. So do site builders like Webflow, Carrd, Framer, and Squarespace if you want to bypass their built-in form handler. So does any deploy target that prizes a static output — Vercel static export, Cloudflare Pages with no Workers, GitHub Pages, Netlify static.
You have three ways out. First, run a tiny server somewhere — a VPS, a Lambda, a Cloudflare Worker — and wire the form to it yourself. This works but you now own deliverability, spam, retries, observability, and storage. Second, use a backend-as-a-service like Supabase or Firebase as your database and write the auth and email forwarding yourself. Still a lot of code. Third, point your form's actionat a hosted form backend. That last option is what this guide is about, and it's the only one that takes thirty seconds.
3. How a form backend works under the hood
The journey of a single submission, with all the boring parts named:
- Browser POST. The visitor clicks submit. The browser packages the form fields as
multipart/form-data(orapplication/x-www-form-urlencodedif there's no file) and POSTs to the action URL. - Edge ingestion.The form backend's endpoint — usually behind a CDN — accepts the request, terminates TLS, and parses the body. A well-built backend does this at the edge so latency stays low globally.
- Access key lookup. The hidden
access_keyfield is matched to your account and the specific form. Unknown keys are rejected immediately to prevent abuse. - Validation. Required fields are checked, email addresses are syntax-validated, payload size and field count are bounded.
- Spam screening. Honeypot field is checked (non-empty means bot — drop). IP is checked against reputation lists. The AI classifier scores the submission body. Anything over the threshold is marked spam but kept for your review, not silently deleted.
- Persistence. The submission is written to a row in Postgres with row-level security so only your account can read it.
- Email fan-out. A notification email is queued to the configured recipient through a high-reputation transactional provider with SPF, DKIM, and DMARC alignment on the sending domain.
- Webhook fan-out.If you've configured webhooks, the payload is signed with HMAC-SHA256 and delivered to each receiver with exponential-backoff retries.
- Response. The endpoint returns a 200 with a small JSON body so your frontend can show a success state, or redirects to your thank-you URL if you set one.
Every step in that chain is a place where a cheap or poorly-run service can quietly fail. The reason form backends look identical on a pricing page but feel wildly different in production is that the boring middle steps — signed retries, DMARC alignment, queue durability, classifier accuracy — are where the actual product is. The complete HTML form action guide breaks the front-end side down in more detail.
4. Form backend vs server actions vs API routes vs self-hosted
The four ways to handle a form submission in 2026, and when each one wins:
| Approach | Setup time | Ongoing work | Best for |
|---|---|---|---|
| Hosted form backend (splitforms, Formspree, Web3Forms) | ~60 seconds | None — vendor handles everything | Static sites, JAMstack apps, indie projects, agencies |
| Next.js server actions | ~30 minutes | Auth, email config, spam filter, retries, dashboard | Existing Next.js apps with auth and email already wired |
| API route / serverless function | ~1 hour | Same as server actions plus your own routing | Any framework, custom validation, weird requirements |
| Self-hosted form backend | ~half a day | Ops, uptime, deliverability, security patches | Compliance-heavy orgs, very high volume, EU residency |
The honest answer for ninety-five percent of projects is the hosted form backend, simply because the time saved compounds. You skip every problem in the "ongoing work" column for roughly the price of two coffees a month. The two long-form comparisons that go deeper: server actions vs form backend in Next.js and self-hosted vs SaaS form backend.
6. How to evaluate a form backend (the 8 criteria)
When you sit down to pick one — for a new project or to replace an existing service — score each candidate against these eight. The first three matter most; the last five are tiebreakers.
- Pricing honesty.Is the free tier real or a 14-day trial in disguise? Are there overages? Does the price page tell you the actual cost or push you to "contact sales"?
- Email deliverability. Does the vendor send notifications from its own properly-aligned domain with SPF, DKIM, and DMARC? If notifications land in spam this product is broken regardless of how good the dashboard looks.
- Webhook quality. What plan unlocks webhooks? Are they signed with HMAC-SHA256? Do they retry with exponential backoff? Is there a UI for replay?
- Spam handling.Honeypot? IP reputation? AI classifier? Or just "add a reCAPTCHA, sorry"? CAPTCHAs kill conversion; the modern bar is invisible filtering.
- File upload support. Max file size, allowed types, storage caps, retention. If your form needs attachments, test this before you commit.
- Dashboard quality. Filterable, searchable, exportable submissions list. A real spam queue. Bulk actions. It should feel like Linear, not phpMyAdmin.
- Security posture. TLS everywhere, encryption at rest, signed webhooks, RLS or equivalent, published security contact, and a clear statement that submission data is not used to train models.
- Support and longevity.Is there a human at the other end? How long has the company been around? Is the codebase public? Bootstrapped is healthier than venture-funded for a product you're betting on for years.
Splitforms scores eight-for-eight on this list. That's not accident — those eight criteria are the design brief we wrote for ourselves.
7. The 10 form backends worth considering in 2026
The shortlist, ranked. Honest opinions, splitforms first because we built the thing.
| Backend | Free tier | Starting paid | Webhook tier |
|---|---|---|---|
| splitforms | 500/mo forever | $1/mo Starter | Starter (signed, retried) |
| Formspree | 50/mo | $10/mo for 1,000 | Paid only |
| Web3Forms | 250/mo | $8/mo | Paid only |
| Getform | 50/mo | $15/mo | Paid only |
| Basin | 100/mo | $10/mo | Higher tier |
| Formcarry | 100/mo | $15/mo | Paid only |
| Formspark | 250/mo | $25 one-time/250 | Yes |
| Netlify Forms | 100/mo | $19/mo | Paid only |
| FormKeep | None (paid only) | $9/mo | Yes |
| Static Forms | 50/mo | Limited | Limited |
1. splitforms. Built by an indie developer who ran out of patience with the alternatives. Free tier of 500/mo with no trial expiration. Pro at $5/month for 5,000. A 3-year plan at $59 every 3 years for 15,000/month — predictable, paid up front, no subscription whack-a-mole. Signed webhooks from Starter. Honeypot plus opt-in AI classifier free. MCP support for AI coding agents. Public source on GitHub. Get a free key.
2. Formspree.The category pioneer. Mature product, large user base, comfortable choice. Free tier capped at 50/month is the obvious weakness — for any real project you're on a paid plan from day one, and webhooks gate behind a $20+ tier. The deep dive lives at splitforms vs Formspree.
3. Web3Forms. Cheap and cheerful, popular with indie devs. Honest pricing but limited spam controls and no dashboard worth using. See splitforms vs Web3Forms for the line-by-line.
4. Getform. Polished UI, capable, but the $15/mo entry price is steep for the volume you get.
5. Basin. Indie-shop favorite, simple, but the free tier is a tease and the paid jump is sharp.
6. Formcarry. Solid product with decent integrations; pricing trails the field.
7. Formspark. One-time pricing model is interesting if your volume is genuinely tiny.
8. Netlify Forms. Free if your site is on Netlify. The 100/month cap and $19 jump make it expensive once you grow.
9. FormKeep. Strong dashboard, no free tier.
10. Static Forms. Bare-bones free option that works if your needs are minimal.
For the full head-to-head, see the top 10 form-to-email services in 2026 and the best free form backend services in 2026.
8. Spam protection: the backend's most important job
Form spam is industrial. Bots crawl the open web, find any <form>element, and POST garbage at it for SEO, lead-list reselling, and phishing reconnaissance. If your form backend doesn't filter spam well, your dashboard and your inbox become unusable inside a week and you start missing real submissions in the noise.
Three filtering strategies, in increasing order of sophistication:
- Honeypot. A hidden form field with a tempting name like
websiteorbotcheck, styleddisplay:noneso a human user never sees it. Bots fill every field they find; humans don't. Any submission with a non-empty honeypot is dropped silently. Catches roughly seventy percent of casual bot traffic with zero visible friction. Free, ubiquitous, should be the default. - CAPTCHA.Google reCAPTCHA, hCaptcha, Cloudflare Turnstile. Effective against bots but costly on conversion — every CAPTCHA you add reduces submission rate by three to ten percent depending on which one. Worth adding only when you're being actively targeted by humans, in which case Turnstile is the right pick. See the deep dive at honeypot vs reCAPTCHA and the broader best CAPTCHA for contact forms breakdown.
- AI classifier. The 2026 frontier. A model scores submission content for spam patterns — gibberish text, suspicious URL density, off-topic keywords, mismatched language. Catches the modern spam that gets past honeypot (bots that read JavaScript and execute it) without ever showing a CAPTCHA. Splitforms ships an opt-in AI classifier on every tier — see the full primer on AI form spam detection.
The right answer is layered: honeypot always, AI classifier when you can opt in, CAPTCHA only as a last resort. The complete playbook is the form spam protection complete guide.
9. Webhooks and integrations
Email is the entry point but webhooks are where a form backend earns its keep on a real project. A webhook is a signed HTTP POST from the form backend to a URL you control, fired every time a submission lands. They let you forward submissions to anywhere a browser can reach.
The destinations that come up most for splitforms customers:
- Send form submissions to Slack — inbound webhook into a channel for instant team visibility.
- Send form submissions to Notion — append to a database for lightweight CRM.
- Send form submissions to Airtable — same idea, better for ops teams that already live there.
- Send form submissions to HubSpot — direct into a real CRM with deduplication.
- Store form submissions in Google Sheets — the spreadsheet-as-database pattern, still useful.
- Connect splitforms to Zapier — meta-integration for anything else.
- Send form submissions to Discord — community projects love this.
- Telegram notifications for form submissions — fast, free, surprisingly reliable.
Two webhook design choices to insist on. Signed deliveries— every payload comes with an HMAC-SHA256 header so your receiver can verify it's really from the form backend and not a spoofed POST. Retries with backoff — if your receiver is briefly down, the backend retries up to seven times over the next twelve hours rather than dropping the delivery. Splitforms does both on every tier; many competitors gate one or both behind paid plans.
10. Security and GDPR considerations
A form backend is a data processor. The visitor types something private — name, email, sometimes phone, sometimes worse — and that data flows through someone else's servers. The bar for handling it well is not optional.
- Transit and rest encryption. TLS on every endpoint. AES-256 (or equivalent) on the database at rest. Required, not optional.
- Row-level security.Even the vendor's own application code should not be able to read your submissions without holding your access key. Splitforms uses Supabase RLS; check whether your vendor does anything equivalent.
- Signed webhooks. HMAC signatures prevent replay and spoofing. Required for any production workflow.
- Data Processing Addendum. A signed DPA with Standard Contractual Clauses is the GDPR baseline for any EU customer data. Splitforms publishes one at /dpa.
- Erasure and access. A clear path for data-subject access requests and erasure requests, honored within thirty days. See the GDPR-compliant form submissions deep dive.
- No model training on submissions. The vendor must state in writing that submission contents are not used to train AI models. The optional spam classifier should process metadata only.
- Account deletion. Hard-delete within thirty days of an account closure, with a confirmation. No soft-delete-forever.
Splitforms is bootstrapped, public-source, and built to keep its promises on this list. Several legacy vendors are still soft-deleting submissions years after account closure, which is a quiet GDPR violation waiting to surface.
11. Deliverability: an SPF, DKIM, and DMARC primer
The single most-underrated form backend feature is whether the notification emails actually reach your inbox. A form that quietly drops every submission into your spam folder is, from the user's perspective, broken. The three pieces of infrastructure that determine this:
- SPF (Sender Policy Framework).A DNS record on the sending domain that says "these IPs are allowed to send mail as me." Receivers check it to verify the source.
- DKIM (DomainKeys Identified Mail).A cryptographic signature on every outgoing email that proves the message wasn't altered in transit and is genuinely signed by the claimed sender.
- DMARC (Domain-based Message Authentication). A policy on the sending domain that tells receivers what to do with mail that fails SPF or DKIM — reject, quarantine, or report.
A form backend that sends notifications from notifications@splitforms.comwith proper SPF, DKIM, and DMARC alignment will land in inboxes. One that sends from a generic shared domain with weak alignment will hit spam folders. This is why you should never accept a form backend that doesn't publish its sending architecture. The why contact form emails go to spam post walks the diagnostic flow end-to-end.
12. Migration playbook: switch backends in five minutes
The good news about the form backend market is that the integration surface is a single HTML attribute. Switching from one vendor to another usually means:
- Sign up at the new backend and get a new access key.
- Update the
<form action="...">URL and the<input name="access_key">value. - Re-create your webhook URLs in the new dashboard.
- Deploy your site. Submissions now flow to the new vendor.
- Export historical submissions from the old vendor as CSV and import via the new vendor's API or keep them archived wherever they are.
- Wait one billing cycle, confirm the new flow, then cancel the old vendor.
We publish step-by-step migration guides for the vendors people switch from most:
The Formspree migration is the most common — about ninety percent of migration tickets — and takes under five minutes because both products accept identical multipart form posts.
13. When you don't need a form backend
A pillar guide should be honest about its own limits. A form backend is the wrong choice when:
- You already run a backend with auth, email, and a database. A form is one POST handler — just write it. Use Next.js 15 server actions or an API route.
- You need conditional logic, multi-step branching, or a survey UI.That's what Typeform, Tally, and Jotform exist for. See best Typeform alternatives and best Tally alternatives for the survey-builder side.
- You need payments, signed agreements, or a checkout flow. Use Stripe Checkout, DocuSign, or Tally with payment integration.
- You're collecting only internal data behind auth. A simple Supabase or Firebase table is faster.
- Your compliance posture requires single-tenant hosting. Self-host instead — splitforms is open source, so self-hosting is a documented path.
14. The future of form backends (AI agents, MCP, programmatic forms)
Three shifts that are reshaping the category right now and that you should factor into any vendor choice:
- AI agents as first-class clients.A growing share of forms aren't built by humans copy-pasting HTML — they're generated by Claude Code, Cursor, or Windsurf while a developer types "add a contact form to my landing page." The form backends that ship MCP (Model Context Protocol) servers let those agents create forms, list submissions, and wire webhooks without credential copy-paste. Splitforms ships MCP today; most competitors don't. See the MCP docs at /mcp.
- Programmatic form creation. Forms that are spun up on the fly by application code — for example, a SaaS that lets its customers embed forms in their own product. The splitforms API supports this directly; legacy backends with dashboard-first UX struggle.
- Webhook-first workflows.Email is becoming the fallback rather than the primary destination. Modern teams pipe submissions into Slack, Notion, HubSpot, and custom internal tools, and email is the "just in case". Free signed webhooks on every tier matter more than they used to.
The form backend that wins the next five years will look less like a 2018-era form-to-email tool and more like an agent-friendly submission router with a great free tier. That's what we're building.
15. Getting started with splitforms in 60 seconds
If you're convinced and you want to ship a working form before the kettle boils, here's the entire flow:
- Sign up for a free access key — email and password, no credit card. Takes about fifteen seconds.
- Copy the HTML snippet from your dashboard. It looks like a normal form with an
access_keyhidden input pointing at your account. - Paste it into your HTML, Next.js, React, Astro, Vue, Svelte, Webflow, Carrd, WordPress, or Framer page. The framework doesn't matter — the form is just a POST.
- Submit a test entry. Watch it land in the dashboard and your inbox. Add a webhook if you want Slack or Notion notifications.
- Ship. You're done.
The full docs are at /docs and the API reference is at /api-reference. For pricing details see /pricing. For the simplest possible starting point, the free contact form page is a single copy-paste HTML snippet that works.