Static hosting solved almost everything. Your site is a folder of files, it deploys in seconds, it costs nothing, and it does not fall over. Then a client asks for a contact form and the whole model runs out of road.
The reason is simple. GitHub Pages, Netlify, Cloudflare Pages and Vercel's static output all serve files. There is no process listening for a POST, no database to write a message into, and no mailer to hand it to. A <form> tag needs somewhere to send data, and a static host has nowhere to put it.
You have four realistic options. They are not equally good.
Option 1: mailto links
You have seen this one. <a href="mailto:[email protected]">Email us</a>, or worse, a form with action="mailto:...".
It requires no service and no code. It also breaks for most visitors. It depends on a mail client being installed and configured, which is not true for anyone using webmail in a browser. The form version produces a garbled draft that people abandon. And publishing a raw address on a public page is an invitation to every scraper on the internet.
Use it for a personal page nobody depends on. Do not put it in front of a client.
Option 2: write a backend
Stand up a small server, or a serverless function, that accepts the POST, validates it, stores it and sends the email.
This is the flexible answer, and sometimes it is the right one. It is also more work than it looks. A contact form that a business actually relies on needs validation, spam filtering, a place to store submissions so a failed email does not lose the message, retry logic when your mail provider is slow, and some way to see what happened when someone says they never got the enquiry.
That is a week of work, and then it is yours to maintain. For a five-page marketing site it is a bad trade.
Option 3: your host's built-in forms
Netlify Forms and a few others detect a form at build time and collect submissions for you.
The setup is genuinely easy: add an attribute and deploy. The catch is that your form now belongs to your host. Move the site to Cloudflare Pages and the form stops existing. The free tiers are also small, and the dashboards tend to be thin, because forms are a side feature rather than the product.
Fine if you are certain you will never move. Most sites move.
Option 4: a form backend service
You point the form at a URL owned by someone whose entire job is receiving form posts.
<form action="https://formjetty.com/f/YOUR_FORM_ID" method="post">
<input name="email" type="email" required>
<textarea name="message" required></textarea>
<button type="submit">Send</button>
</form>
That is the whole integration. No JavaScript, no build step, no server. It works on any static host because it is just an HTML form posting to an external URL, which is a thing browsers have done since 1995.
This is what most people should use, and it is the category FormJetty sits in.
What to actually check before you pick one
The services in this space look interchangeable on their pricing pages. They are not. A few things separate the ones you will still be happy with next year.
Does it store the submission, or only email it? This is the big one. Several services are a mail relay with a nicer front end: they receive the post, send an email, and forget. If the email bounces, is filtered as spam, or lands in an inbox nobody reads, the message is gone. There is no record to go back to. Storing the submission first, then treating the email as a separate delivery, is the difference between losing enquiries and not.
Can you see what happened after the send? When a client tells you the form is broken, you need to know whether the submission arrived, whether it was scored as spam, and whether the notification went out. If the answer is a support ticket, you have bought yourself a permanent support burden.
Is spam held or dropped? Filtering that silently deletes is filtering you cannot audit. Held spam that you can review and rescue is safer, and it means a false positive costs you a click instead of a customer.
Does validation run on the server? Client-side required attributes are a nicety for humans and no obstacle at all to a bot posting directly to your endpoint. If the service does not check field types and lengths on its side, your inbox is only as clean as the internet is polite.
Can you get your data out? CSV or JSON export, on demand, without asking. If the answer is unclear, assume no.
The honest summary
For a static site, a form backend service is the right default. It keeps your site static, takes about a minute to wire up, and moves the boring, failure-prone parts to someone else.
Pick one that stores submissions rather than forwarding them, and that can tell you what happened to each one. Everything else on the comparison table matters less than being able to answer the question "did it arrive?" without guessing.
FormJetty's free plan is 500 submissions a month with every feature included, spam inbox and delivery log and all. Create an endpoint and point a form at it.