Contact Forms on Static Sites: The Problem, and Every Way to Solve It

Static sites won. Astro, Hugo, plain hand-written HTML, and increasingly a first draft spat out by an AI builder — they’re fast, cheap to host, and there’s almost nothing to break. You ship files to a CDN and walk away.

Then someone asks the one question that quietly undoes all of it: “How do people actually contact us?”

A contact form sounds like the most trivial feature on the web. It is not — not on a site with no server. This is a look at why that is, and an honest comparison of every way people solve it, from the crude to the clean.

Why a form breaks the “no backend” promise

Everything else on a static site is a one-way street: the server sends HTML, the browser renders it, done. A form is the one element that has to send data back somewhere. The instant you write <form>, you’ve signed up for four problems that have nothing to do with your nice static site:

• Something has to receive the POST. A form submits to a URL. That URL needs code running behind it. Congratulations — your zero-ops static site now has a backend, a runtime to patch, and a bill.
• Spam finds you fast. Publish a bare, public form and bots start filling it within days. Now you’re either bolting a CAPTCHA onto a clean design (and annoying real humans) or hand-writing honeypot and rate-limit logic.
• Delivery is its own project. An email to the site owner, a stored copy so nothing is lost, maybe a Slack ping or a spreadsheet row. Each destination is plumbing someone has to build, wire up, and keep working.
• You’re now holding personal data. A name, an email, a message — that’s PII sitting in your storage. Which means encryption at rest, a retention policy, and a GDPR conversation you probably didn’t plan for.

For a brochure site, that’s a genuinely absurd amount of infrastructure to babysit, and every piece of it can page you at 2am. So the real question isn’t “how do I add a form” — it’s “how do I add a form without re-inventing a backend.”

The options, honestly compared

There are really only a handful of approaches. Here’s what each one actually costs you.

mailto: links. The zero-infrastructure escape hatch: <a href="mailto:[email protected]">. No form, no server, no spam handling. It = also has no validation, no spam protection, no record of what was sent, and it depends on the visitor having a mail client configured — which on a phone or a shared computer, they often don’t. Fine for a personal page. Not a contact form.

Your host’s built-in forms. Netlify Forms, Vercel’s integrations, and similar detect a form at build time and capture submissions for you. This is a real option and genuinely convenient if you’re on that host — but it locks form handling to your deploy platform, the free tiers are tight (Netlify’s is 100 submissions/month), and your routing and spam options are whatever that vendor decided to ship. Move hosts and your forms move with them.

Roll your own serverless function. A small Cloudflare Worker, Lambda, or API route that receives the POST, checks for spam, sends an email, and stores the result. Maximum control, and it keeps the marginal cost near zero — but you are now the author and on-call owner of a tiny backend per site. Spam logic, email deliverability, a database, secrets, retention: all yours to build and maintain. It works. It just doesn’t scale across more than a couple of sites before it becomes a part-time job.

A hosted form backend. Point the form’s action at a URL that some other service operates, and let it own the POST, the spam filtering, the storage, and the routing. You add zero infrastructure; the form stays plain HTML. This is the approach that has quietly become the default for JAMstack and AI-built sites, because it’s the only one that keeps a static site actually static.

What to look for in a form backend

“Hosted form backend” is a category, not a product, and they vary. The ones worth using tend to share a few traits:

• The integration is literally one line — a <form action>, no SDK to install and no API keys living in your frontend where anyone can read them.
• Spam is handled server-side — honeypots, rate limiting, and velocity checks that don’t require dropping a CAPTCHA onto your design.
• Routing is built in — inbox, email notifications, webhooks, and drop-ins for Slack, Google Sheets, Notion and the like, so you’re not standing up Zapier just to move a message into a spreadsheet.
• Privacy is their architecture problem, not yours — submissions encrypted at rest, IPs hashed, retention configurable, so “where does this data go and for how long” has a real answer.
• It doesn’t care what built the page — because it’s a plain form post, it behaves identically whether the HTML came from Astro, React, Hugo, or an AI builder.

ShipMyForm is a clean example of the category — a form backend built for static sites that does exactly the list above and not much else. It’s the reference point for the rest of this piece because the one-line integration makes the trade-off easy to see.

The one-line version

Here’s the entire integration with a hosted backend. This is the whole thing:

<form action="https://shipmyform.com/f/YOUR_FORM_ID" method="POST">  
 <input name=email type=email required> <textarea name=message></textarea> <button>Send</button></form>  

No fetch() wrapper, no serverless function, no keys in the client. Because it’s a standard form post, it works the same on any stack. If you’d rather see the exact markup for your own fields before signing up for anything, a free contact-form generator will produce the snippet for you, and there are drop-in guides for React, Astro and more when a framework wants something fancier than plain HTML.

So which one should you use?

Honestly:

• A personal page with nothing to protect? A mailto: link is fine. Ship it.
• All-in on one host and low volume? The built-in forms are the path of least resistance — just know you’re marrying your host.
• One site, and you enjoy owning infrastructure? Roll the serverless function. You’ll learn a lot and it’ll cost pennies.
• Anything you have to maintain across time or across sites? Point the form at a hosted backend and stop thinking about it. A contact form should take five minutes and then never be considered again.

The reason the last option has become the quiet default is simple: it’s the only one where adding a form doesn’t cost you a backend. And because a good one starts free — a real free tier, not a 14-day trial — you can wire up a working, spam-filtered contact form before there’s even a budget conversation, then upgrade only the sites that grow into it. “Just use a static site” was always good advice. It’s better advice once the one part that needs a server no longer does.

The Web Tier writes about building fast, modern websites without the operational baggage. We publish practical guides on the tools and patterns that keep static sites simple.