Handling forms on a static site: every option compared

Forms are the second thing that trips teams up on static sites, right after content editing. Every marketing site has at least one: contact, quote request, newsletter, event sign-up. On WordPress you install a plugin. On a static site there is no server to post to, so you need a plan.

The good news is that this is a solved problem with several reasonable answers. This guide compares them honestly, including the costs that are easy to miss: spam, notifications, and what happens to people’s personal data afterwards.

Why forms are hard on a static site

An HTML form needs somewhere to send its data. On a dynamic site, the same server that builds pages also receives the submission, stores it and sends an email. A static site is only files. The host hands them out and has nothing listening for a form post.

So a static site form always sends its data somewhere else. The options differ in where that is, who looks after it, and how your team reads what comes in.

The one option to rule out early is a mailto: link dressed up as a form. It opens the visitor’s email app, if they have one set up, and gives you no record, no spam filtering and no structure. It is fine as a fallback link, not as a form.

Hosted form services

A hosted form service gives you an endpoint URL. You set your form’s action attribute to that URL, and the service receives submissions, filters spam, stores them and notifies you.

<form action="https://forms.example.com/f/your-form-id" method="post">
  <label>Name <input name="name" required></label>
  <label>Email <input name="email" type="email" required></label>
  <label>Message <textarea name="message"></textarea></label>
  <button>Send</button>
</form>

Good for: most marketing sites. You keep full control of the HTML and styling, setup takes minutes, and you can move the form between hosts without changing anything.

Watch for: where submissions are stored and for how long, how many your plan allows, whether your team gets a shared inbox or just forwarded emails, and how easy it is to export your data if you leave.

Host-provided forms

Some static hosts include form handling. You add an attribute to your form and the host captures submissions during deploy and in production.

Good for: simple sites already on that host, where you want one less account.

Watch for: it ties your forms to your host. Moving hosts later means redoing your forms. Features and limits vary a lot, and submissions are often only visible in the host’s dashboard, which your marketing team may not have access to. Check the current limits on your host’s pricing page.

Serverless functions

Most static hosts can also run small pieces of code on demand, often called serverless or edge functions. You can write a function that receives the form post, validates it, and sends an email or saves it somewhere.

Good for: teams with a developer who want full control, or forms that need custom logic such as calling another system.

Watch for: you now own code that handles personal data. You are responsible for spam protection, validation, storing or forwarding submissions, error handling and keeping dependencies up to date. That is a small application, and it needs looking after like one. It also usually leaves the marketing team with no inbox of their own, only emails.

Embedded third-party forms

Form builders and many marketing platforms let you design a form in their app and embed it with a script or iframe.

Good for: teams who want non-developers to build and change forms, or who need the form wired straight into a marketing platform.

Watch for: the form loads someone else’s code and styling into your page. It may not match your design, it can slow the page down, and it may set cookies or track visitors, which affects your privacy notice and consent banner. Accessibility varies.

Spam protection

Any public form gets spam. How it is handled matters as much as where the form posts.

Common layers, from least to most intrusive for visitors:

• Honeypot fields. A hidden field that people leave empty and simple bots fill in. Invisible to real visitors and surprisingly effective.
• Timing checks. Submissions that arrive a second after the page loads are rarely human.
• Rate limiting. Limiting how many submissions come from one source in a short time.
• Content filtering. Scoring submissions for spammy patterns and links.
• Challenge widgets. Tests that ask the visitor to prove they are human. Effective, but they add friction and some send visitor data to a third party.

A good setup uses the invisible layers first and keeps challenges as a last resort. Whatever you choose, make sure there is a spam folder you can check, so real enquiries that get caught are not lost.

Notifications and where submissions go

This is the part most comparisons skip, and it is where teams feel the pain.

If every submission is just an email to one person, enquiries get lost when that person is away, nobody knows which ones were answered, and the history lives in one inbox. Better options:

• A shared inbox where the team can read submissions, mark them handled and search past ones.
• Notifications to several people, with the option of a daily or weekly digest instead of one email per submission.
• Exports to a spreadsheet for reporting.
• Integrations with other tools, where the form service supports them.

Ask who needs to see submissions and how they work today, then pick an option that fits that, rather than forcing everyone to share a login to a developer dashboard.

Privacy and data retention

Form submissions are personal data. Wherever they end up, you should know:

• Where they are stored, and in which country.
• Who can see them.
• How long they are kept, and whether you can delete them.
• Whether the service uses them for anything else.

Mention the form service in your privacy policy, keep only what you need, and delete old submissions on a schedule. Check what the privacy law that applies to you requires.

Comparison table

Which option to choose

• Most marketing sites: a hosted form service with a team inbox. You keep your own HTML, the form survives a change of host, and nobody has to maintain code.
• Very simple sites already on a host with forms: the host’s feature is fine, as long as you accept the lock-in.
• Custom logic or integrations: a serverless function, if you have someone to look after it.
• Forms that live inside a marketing platform: embed theirs, and accept the design and privacy trade-offs.

Forms are also a security surface. See static site security for how they fit into the bigger picture, and shortfalls of static sites for the other gaps worth planning for.

My take

I would use a hosted form service for almost every static marketing site, and I would choose it on the boring things: a proper team inbox, sensible spam handling without annoying visitors, clear data retention and easy export. The endpoint itself is the easy part.

That is why Mabel includes a form inbox alongside content editing, so the same people who edit the site can read and handle what comes in. Whatever you use, the test is simple: when someone fills in your form on a Friday afternoon, does the right person see it on Monday morning?