How to handle form submissions without a server

Every contact form, signup form, and survey on the web eventually has to answer the same question: where does the data go? Browsers know how to send it. The hard part is receiving it, validating it, storing it, and routing it to the right place — all without losing a message, leaking data, or getting buried in spam.

This guide explains what actually happens during a form submission at the protocol level, then walks through three ways to handle submissions — your own server, a serverless function, and a form backend — with an honest account of the trade-offs.

The request lifecycle of a form POST

Understanding the lifecycle helps you debug problems and make a better choice about where to handle the work.

When a visitor clicks Submit on an HTML form:

1. The browser serialises the fields. Every <input>, <textarea>, and <select> with a name attribute is collected into a key-value payload. The encoding depends on the form's enctype: application/x-www-form-urlencoded is the default; multipart/form-data is used when the form includes file uploads.

2. The browser sends a POST request to the URL in the action attribute, with the encoded payload as the request body. This is a standard HTTP request — there is nothing magical about it.

3. The server receives the request. A process on the other end reads the body, validates the fields, and decides what to do.

4. The server responds. For a traditional HTML form, the server typically responds with a 303 See Other redirect. The browser follows the redirect and the visitor lands on a new page. Alternatively, the server can respond with a JSON body — useful when submitting via fetch in JavaScript rather than a native browser form POST.

The important thing to notice: step 3 requires a server. Something has to be running at that URL, waiting to receive the request. On a static site, there is nothing there.

Option 1: your own server

Running your own server gives you complete control. You write the handler, choose the language, store data wherever you like, and integrate with whatever downstream systems you need.

Pros:

• No submission limits imposed by a third party
• Data stays entirely within your infrastructure
• Full flexibility over validation logic, storage schema, and routing

Cons:

• You have to provision and maintain the server — or pay someone to
• You write the email-sending code (SMTP credentials, deliverability headaches)
• You handle spam filtering yourself
• Security is your responsibility: rate limiting, input sanitisation, authentication
• Server downtime means missed submissions

For a high-traffic application with complex submission processing requirements, running your own server is often the right answer. For a contact form on a portfolio site, it is almost always overkill.

Option 2: a serverless function

Serverless functions — AWS Lambda, Cloudflare Workers, Vercel Edge Functions, Netlify Functions — reduce the infrastructure burden. You write a function that handles the POST, and the platform manages scaling and availability.

Pros:

• No persistent server to manage
• Pay for what you use (often free at low volume)
• Can be co-located with your static site on the same platform

Cons:

• You still write the handler code, including email delivery
• SMTP or transactional email setup (SendGrid, Resend, Postmark) adds complexity and cost
• Cold starts can cause occasional slow responses
• Spam filtering is still your problem
• Debugging across platform logs is more friction than it looks

Serverless functions are a good fit when you have existing infrastructure on a platform like Vercel or Cloudflare, need custom processing logic (for example, writing to a database or calling a third-party API), and are comfortable maintaining the glue code.

Option 3: a form backend

A form backend is a dedicated service that accepts form POSTs, handles everything in the middle, and delivers submissions to you. You swap your form's action URL to point at the backend's endpoint, and the service takes care of the rest.

What a form backend handles:

• Receiving the POST. Standard application/x-www-form-urlencoded and multipart/form-data bodies, including file uploads on plans that support them.
• Validation. Reject submissions with missing required fields, invalid email formats, or fields that exceed size limits.
• Spam detection. Honeypot fields, CAPTCHA challenges, and per-IP rate limiting — layers of protection you would otherwise have to build yourself.
• Storage. Submissions are stored in the service's dashboard so you can review, filter, and export them. Retention periods depend on the plan.
• Email notification. The submission is emailed to your verified destination addresses. You get the data without touching SMTP configuration.
• Integrations. Webhooks let you forward submissions to any external system — a CRM, a Slack channel, a Zapier workflow, a custom endpoint.

The trade-off is that you are dependent on the service's availability, submission limits, and pricing. You also trust the service with the data your visitors submit.

How Formcrest fits this picture

Formcrest is a form backend. You point your form at https://api.formcrest.com/v1/submit/{your-form-id} and Formcrest handles the rest.

On the spam side, Formcrest runs three independent layers by default: a honeypot field (_honey), optional Cloudflare Turnstile (available on every plan, including free), and automatic per-IP and per-form rate limiting at the edge. Spam-flagged submissions are stored in the dashboard but never delivered to your inbox and never count against your monthly submission quota.

On the notifications side, submissions are emailed to your verified destination addresses. The Free plan supports one destination email; Pro (€18/mo) supports 15; Agency (€40/mo) supports 30. If you need more destination emails than a plan includes, stackable top-ups add 20 more for €5/month each.

For integrations, Pro and Agency plans include HMAC-signed webhooks, so you can route submissions to any external system without running intermediary code.

The Formcrest submit endpoint returns a 303 redirect for plain HTML form POSTs (following the submission to your success URL, or the default thank-you page) and a JSON body when the request includes Accept: application/json. This makes it work equally well with native browser form submission and with fetch-based AJAX workflows. Full documentation is at /docs.

For notification configuration — how to set up email digests, custom subject lines, Reply-To and BCC fields — see /docs/forms/notifications.

When to choose each option

Here is a practical guide:

Situation	Recommended approach
Portfolio, landing page, or documentation site	Form backend
Form on a Vercel or Cloudflare project where you already have edge functions	Serverless function
Application with complex submission logic (write to your own DB, trigger workflows)	Own server or serverless
Agency managing forms across multiple client sites	Form backend (look for multi-destination support)
Regulated data (health, finance) requiring specific data residency or DPA	Form backend with explicit EU residency, or your own server

The dividing line is roughly: if the only thing you need to do with a form submission is receive it, store it, and get an email, a form backend eliminates all the accidental complexity. If you need to do things with the data that require custom code — enrichment, database writes, branching logic — a serverless function or server is the right layer for that logic.

Switching approaches later

One of the practical advantages of form backends is how easy they are to adopt and abandon. Your form is still plain HTML. If you later decide to move submission handling in-house, you change the action URL and replicate the validation and email logic. Nothing about your form markup has to change.

The same is true in reverse: if you are currently running a serverless function that sends email via SendGrid and you are tired of maintaining it, migrating to a form backend is a single attribute change plus a destination email verification.

Getting started

If a form backend is the right fit for your project, create a free Formcrest account and have a working form in under ten minutes. No credit card required for the Free plan, which includes 500 submissions per month. The 14-day Pro trial — also requiring no credit card — gives you access to the full feature set so you can evaluate webhooks, multiple recipients, and custom email options before committing to a paid plan.