Adding a Contact Form to a Static Site

September 22, 2026

A static site cannot receive form submissions by itself, because there is no server code to handle them. To add a contact form, you either use a form service that receives the data for you, use a feature built into your host, or add a small serverless function. For most small sites, a form service or a host feature is the simplest option and takes under an hour.

If all you need is a way for people to reach you, a plain email link may be enough. A form is worth adding when you want structured messages and a more welcoming experience.

Why a static site cannot handle forms alone

An HTML form collects text and sends it to an address when the visitor presses submit. Something at that address has to receive the data, validate it and send an email or store it. A static host only serves files, so there is nothing at the receiving end.

The workaround is to point the form at a service that does have something there. That service handles the receiving and forwards the message to you.

Option one: a host’s built-in feature

Some hosts include form handling. You add a marker to your form, and the host captures submissions and lists them in a dashboard, or emails them to you. This is convenient if you are already on that host, because there is no extra account.

Check the current limits, such as the number of submissions per month on the free plan, and what spam filtering is included. Also check how to turn on notifications, since a form that stores messages without telling you is easy to forget.

Option two: a third-party form service

Several services provide a web address you can use as the form’s destination. You sign up, create a form, and copy the address into your HTML. Submissions then arrive in your inbox or dashboard.

Compare what they offer: monthly limits on the free plan, spam protection, file uploads and where data is stored. Read the privacy policy, because you are sending your visitors’ messages through a third party. Ask your assistant to adapt the form markup to the service’s instructions, and give it the documentation link or text.

Option three: a serverless function

If you want full control, a small function on your host can receive the form and send an email through an email service. This involves API keys, which must stay on the server, and it takes more setup. It suits people who have built a few projects and are comfortable following host documentation. For a first form, one of the earlier options is usually enough.

Build the form

A good contact form is short. Name, email and message are enough. Every extra field reduces the number of people who finish it. Ask your assistant for markup that includes:

• Labels connected to each field, which helps people using screen readers.
• The right input types, such as type="email", so phones show suitable keyboards.
• Required fields, with a clear message if one is missing.
• A message after sending that confirms what happened.
• A layout that works on a narrow phone screen.

Keep the wording friendly and say what will happen: “We read every message and reply within a few days.” Do not promise what you cannot do.

Deal with spam

Public forms attract spam from bots. Reasonable defenses include:

1. A hidden field that humans do not see; bots tend to fill it, and you discard those submissions.
2. A simple challenge service offered by many form tools.
3. Server-side filtering, if your form service supports it.
4. Rate limiting on submissions.

Avoid puzzles that make real visitors work hard. Test with a real submission and with an obviously fake one.

Privacy and legal points

A form collects personal information, such as names and email addresses. Say why you are collecting it and what you will do with it, in a short note near the form. Depending on where you and your visitors live, rules about personal data may apply. For anything beyond a simple personal site, check official guidance or ask a professional.

Do not collect more than you need, and delete messages you no longer need.

Test it fully

Before you publish, send yourself a test message and verify that:

• The message arrives where expected, with all fields.
• The confirmation appears for the visitor.
• Missing fields trigger a helpful message.
• The form works on your phone.
• Messages do not land in the spam folder.

Check again after any change to the site or your email settings.

A simple fallback

Even with a form, show a plain email address or mailto link somewhere on the page. Forms break: a service goes down, a limit runs out or a setting changes without notice. A visible fallback means a visitor with a real question can still reach you.

Be aware that a public email address attracts spam too. If that worries you, write it in a way that bots are less likely to read, or use a dedicated address that you do not mind filtering. Check your form’s submissions and your spam folder on a regular schedule, perhaps weekly, so a message from a real person does not sit unnoticed for a month.

Finally, reply promptly when you can. A form that collects messages and never answers is worse than no form, because it creates an expectation you do not meet.

Next steps

Decide whether a mailto link or a form fits your site. If you choose a form, try your host’s feature first. Build the three-field form, test it from your phone, and send a test message that is long and contains special characters. Record the service, its limits and the notification setup in your notes file.