HTML contact form, written in full: the contact form HTML a static site pastes in, and where it posts

Ask for four things, and resist the fifth

A name so you know who is writing, an email address so you can answer, an optional subject if it genuinely helps you triage, and the message. That is the complete list for almost every site. Every extra field costs you submissions, and the fields people add first are the ones they want rather than the ones the visitor came to give: a phone number nobody wanted to leave, a company name on a personal enquiry, a dropdown of departments the visitor cannot possibly map their question onto. Ask for less and answer faster.

How to create a contact form in HTML: write the form element first

Start with the container, because two of its attributes decide everything that follows. method="post" keeps what somebody typed out of the query string, out of browser history and out of your logs. action is the URL the browser sends the submission to, and on a static host there is nothing at your own domain that can receive it, so this attribute is the whole of the problem: it has to point at something that accepts a POST. Get those two right and the rest of the form is just fields.

One labeled control per thing you want to know

Every control gets its own label element, bound with for and id, and not a placeholder pretending to be one: a placeholder disappears the moment somebody types, which is exactly when they need to know what the field was. Choose the input type by what the answer is, because the type is what makes a phone show the right keyboard and the browser check the shape of an address. A message is a textarea, not a long text input. On the worked example beside this page, five separate questions come to 8 controls once the group of options is counted properly, and 8 label elements with them.

Decide what happens after the submit button

A form is finished when you know where the submission goes and what the person sees next. The browser will post to the action URL and then render whatever comes back, so something has to reply, and it has to reply with something a human can read. Required attributes will have caught the empty fields, but nothing has checked anything that matters yet, because the browser is not yours. Whatever receives the post has to validate it again, store it, and tell the person it arrived.

Know what required promises, and what it does not

Adding required to a control makes the browser refuse to submit while it is empty and show a message next to it, with no round trip and no JavaScript. That is a real improvement for the person filling the form in, and it is not a rule you can rely on. The browser belongs to them, not to you: developer tools can remove the attribute in a second, and nothing stops a script posting whatever it likes straight at your action URL. Treat every constraint attribute as a courtesy that saves a round trip, and check the same things again wherever the submission actually lands.

Point the action at something that can answer

This is the part the snippets skip. If your page is served from object storage or a static host, there is no process at your domain to receive a POST, so the action has to point somewhere that can: a serverless function you write and deploy, a small server of your own, or a hosted endpoint built for exactly this. Whichever you choose, it has to do three things: validate the submission again, do something durable with it so it is not only an email that can be lost, and reply with a page a human can read, because the browser will render whatever comes back.

Show the visitor a page that says it arrived

The browser posts and then renders whatever the action URL returns, so something has to answer with a page a human can read. A confirmation that says the message arrived and when to expect a reply is worth more than a clever animation, because the alternative is somebody who cannot tell whether it worked sending the same message three times. If the form submits with JavaScript instead, the same rule holds: say plainly that it arrived, and say what happens next.

Stop the spam without stopping the people

A public contact form gets automated submissions from the day it is indexed. Most of it is stopped by unremarkable measures: a hidden field that only a bot fills in, a check on how quickly the form was completed, rate limiting at the endpoint. Reach for a visible puzzle last, because every one of them costs real submissions from real people, and the ones it costs you most are exactly the visitors you were hoping to hear from.