Form Backend for Static Websites

What counts as a static website

A static website is a set of files, HTML, CSS, JavaScript and images, served exactly as they are stored. Nothing is computed on a server when a page is requested, which is why static hosting (GitHub Pages, Netlify, Vercel, Cloudflare Pages, a plain web server) is fast and usually free or close to it. Portfolio sites, business brochure sites, landing pages, documentation sites and most marketing pages are static, and so are the exported builds of many React, Next.js and Vue projects.

The one thing a static HTML form cannot do

An HTML form is only the front half of the conversation. It can ask questions and package the answers, but the action it submits to has to be a live program that receives the data, and a folder of static files contains no such program. Point the form at another static page and the submission simply vanishes. Point it at a mailto: link and the visitor's email app opens instead, which many visitors abandon, and nothing is stored anywhere either way.

So the limitation is precise: a static website can display a form, but it cannot receive, store, or notify you about a submission. Something server-side has to exist. The only question is whether that something is yours to run.

The fix: a hosted form endpoint

A form backend for a static website is a hosted endpoint: a URL, run by a service, that accepts your form's POST requests. Your site stays exactly as static as before. The form simply sends its data to an address that is staffed, by a service whose whole job is to check each submission, store it, and deliver it to you. Form Backend Tool is one such service, and the steps below use it as the example; the shape of the solution is the same whichever provider you pick.

Connecting an HTML form to the endpoint, step by step

1. Create an account and a form. On the Free plan no credit card is needed. Each form you create gets its own endpoint URL with its own key, so different pages or sites can use different forms.
2. Set the notification email. This is the address each submission is delivered to. It has to be verified before notifications are sent to it.
3. Point your form at the endpoint. Either paste the ready-made snippet from the form's page in the dashboard, or take your existing form and set its action to the endpoint and its method to POST.
4. Add the two optional fields that matter. A hidden _redirect field sends the visitor to your own thank-you page after a successful submit, and the _honey honeypot field quietly traps spam bots.
5. Submit a test. Send one submission from your live page and confirm it appears in the dashboard and in your inbox. Then you are done.

The complete form, exactly as the docs publish it:

<form action="https://form-backend-tool.vercel.app/api/forms/YOUR_FORM_KEY" method="POST">
  <label>Your name <input type="text" name="name" required></label>
  <label>Your email <input type="email" name="email" required></label>
  <label>Message <textarea name="message" required></textarea></label>

  <!-- Optional: after a successful submit, send the visitor to your own page.
       Must be an absolute http:// or https:// URL. -->
  <input type="hidden" name="_redirect" value="https://your-site.example/thanks">

  <!-- Honeypot: leave this empty and hidden. People never see it;
       bots fill it in, and those submissions are flagged as spam. -->
  <input type="text" name="_honey" style="display:none" tabindex="-1" autocomplete="off">

  <button type="submit">Send</button>
</form>

The documentation version explains each field, and the redirects section covers the success behaviour in detail. If you would rather follow one complete contact form from an empty page to a tested submission, the step by step tutorial does exactly that.

What happens after a successful submission

When a visitor submits, the endpoint checks the request first: format and size, a rate limit per visitor, and the honeypot. A clean submission is then stored before anything else happens, so a delivery hiccup can never lose it. From there it appears under Submissions in your dashboard, where you can read, filter, mark read and export to CSV, and an email with every field the visitor filled in lands in your notification inbox. Submissions caught as spam are flagged in the dashboard instead of emailed to you. The visitor, meanwhile, is sent to your _redirect page, or gets a JSON response if your page asked for one.

Forms this works for

Contact forms

The classic case: name, email, message. Nothing about it needs a server of your own, it needs the message to arrive reliably and be kept.

Quote and request forms

Service businesses collect a few more fields: phone, type of job, preferred date, details. Same flow, more fields; the endpoint accepts up to 50 fields per submission.

Lead forms on landing pages

A landing page is usually the most static page of all, often a single HTML file. A hosted endpoint keeps it that way while every lead is stored and emailed, instead of depending on the visitor's mail app.

Portfolio and business websites

Freelancers and agencies ship many small sites, and each one needs its form to deliver to a different inbox. A separate form, endpoint and notification address per site keeps client mail apart without a backend per client.

Optional: submit with JavaScript instead

The plain HTML form above needs no JavaScript at all, which is the right default for a static site. If you want to stay on the page and show your own success message, the same endpoint accepts JSON from a fetch call:

await fetch("https://form-backend-tool.vercel.app/api/forms/YOUR_FORM_KEY", {
  method: "POST",
  headers: { "Content-Type": "application/json", Accept: "application/json" },
  body: JSON.stringify({
    name: "Ada",
    email: "ada@example.com",
    message: "Hello from my static site",
  }),
});

Treat this as an enhancement, not a requirement. The docs show the same pattern for other stacks.

Hosted endpoint vs your own backend, for a static site

Building your own backend for a static site means ending the thing that made the site attractive: now there is a server or serverless function to write, a database to keep, email delivery to configure, spam to fight, and a deployment to maintain, all so one form works. For a form that is central to a product, that can still be the right call; the companion article works through that decision in full. For the ordinary contact, quote and lead forms on static sites, a hosted form backend keeps the site serverless and reduces the form to a URL change.

When this is not the right solution

A hosted form endpoint is deliberately narrow, and some forms fall outside it. For Form Backend Tool specifically:

• File uploads are not stored. A job application form that must receive a CV, or any form whose point is an uploaded file, is not a fit: file inputs are ignored and only text values are kept.
• No outgoing webhooks. If every submission must be pushed straight into your CRM or another system, this service does not do that; delivery is the dashboard and email (plus WhatsApp alerts on paid plans).
• No autoresponder. The visitor does not receive an automatic confirmation email from the service.
• Limits apply. 25 KB per submission, up to 50 fields, 10 submissions per 60 seconds per form per visitor, and monthly quotas per form of 250 (Free), 2,500 (Pro) or 10,000 (Agency). The full list is in the docs limits section and the not supported list.

If none of those rule your form out, the fastest way to judge the flow is the live demo on the homepage: it posts to a real endpoint, and what you see is what your visitors' submissions would do. Setup details live in the documentation, and questions go to the support page, where the founder answers himself.