What is a form backend? (And when a static site needs one)

What happens when you press Submit

An HTML form is a set of fields plus two instructions: where to send them (action) and how (method). When a visitor presses Submit, the browser packages the fields and sends an HTTP request to the action URL. That is the whole job of the front end.

Whatever sits at that URL is the backend. On a WordPress site it is PHP running on the same server. On a Rails or Django app it is a controller. Its job is everything after the request arrives:

• Receive the request and read the fields.
• Check it: required fields, sensible values, and whether it looks like spam.
• Store it, so nothing is lost if the next step fails.
• Deliver it: an email to you, and often a copy to a spreadsheet, chat app or CRM.
• Respond to the browser, with a thank-you page or a JSON answer the page can show.

A form backend is any service that does those five things. The term usually means a hosted one: a service that gives you a URL to put in action and handles the rest.

Why static sites don’t have one

A static site is a folder of HTML, CSS and JavaScript files served as they are. That is why it is fast, cheap and easy to host on GitHub Pages, Cloudflare Pages, Netlify or Vercel. It is also why a form on it has nowhere to go: there is no program running on the server to receive the request.

Sites built with Astro, Hugo, Eleventy or Jekyll are static unless you add server code. So are most sites exported from site builders, and a lot of sites generated by AI tools. Those tools produce a convincing form, but the receiving half is often missing or a placeholder, which is why AI-built forms fail without any error.

When a static site needs a form backend

Not every form needs one. A search box that filters the page, or a calculator, never leaves the browser. You need a backend when the data has to reach a person or another system:

• Contact and enquiry forms, where someone expects a reply.
• Quote, booking and lead forms, where a lost submission is lost business.
• Feedback, waitlist and sign-up forms you want to keep a record of.

If a missed message would cost you something, the form needs a backend that stores before it delivers, and tells you when delivery fails.

Your options

1. A mailto link

A mailto: link opens the visitor’s own email app. No backend, but no form either: visitors without a configured mail app get nothing, your address is public, and you get no record. Fine as a fallback, weak as the only way in.

2. Build it yourself

A serverless function or API route on your host, plus an email provider with a verified sending domain, plus a database for storage, plus spam protection. It is flexible and you own it. You also own the failures: expired API keys, a provider outage, spam waves, and the email that silently stopped sending months ago. A reasonable choice if your project already runs a backend.

3. Your host’s built-in forms

Some hosts collect form submissions for sites they build. It is convenient while you stay on that host, and your forms move with the host decision. We compare one of these in Netlify Forms vs FormRill.

4. A hosted form backend

You point the form’s action at a URL from the service, and it handles receiving, spam, storage and delivery. There are many: Formspree, Web3Forms, Basin, Formcarry and others, and FormRill is one of them. The change on your site is one attribute:

<form method="POST"
  action="https://api.formrill.com/YOUR_FORM_ID/submit">
  <input type="checkbox" name="botcheck" hidden />
  <input type="text" name="name" required />
  <input type="email" name="email" required />
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

How to choose a hosted form backend

The differences that matter show up after launch, not on the pricing page headline:

• Free limits that fit a real site. Free plans range from a few dozen to a thousand or more submissions a month, and some allow only one form.
• What happens over the limit. Some services reject submissions past the cap and don’t keep them. Others keep accepting and ask you to upgrade.
• Stored before delivered. If the email fails, is the submission still somewhere you can see and resend it?
• Spam protection visitors don’t notice. A hidden honeypot field catches most bots without making people solve a CAPTCHA.
• Where else it can send. Email first, then whatever you use: Telegram, Google Sheets, webhooks, n8n or a CRM.
• Reply-to. Pressing Reply on the notification should reach the visitor, not a no-reply address.

Our form backend comparisons lay these out for each service, with sources, including where another service is the better fit.

What FormRill does

FormRill is a hosted form backend. Your form posts to https://api.formrill.com/<form_id>/submit, with no key field. Each submission is stored before delivery, emailed to you with reply-to set to the visitor, and shown in a dashboard with a delivery log you can retry from. A hidden honeypot stops bots with no CAPTCHA. The free plan covers 500 submissions a month on unlimited forms.

Set one up on your stack

• Plain HTML

  Any static site, any host.

• Astro

  A static Astro site, no adapter or SSR.

• Next.js

  A client component with loading and error states.

• Hugo

  A partial, a shortcode and one config value.

• GitHub Pages

  Jekyll or plain HTML Pages sites.

• Lovable, v0, Bolt or Cursor

  A prompt that wires up the form your AI tool built.