Forms: how a person sends something

A form is a <form> element with labeled fields that a visitor fills in to send data to a server. The browser checks it using attributes like required.

A form: what the site is for

Everything we’ve done so far, the visitor reads. A form is the one place they answer: they leave an inquiry, book, order, subscribe. So the form decides whether the site achieves what it was built for: your main action from the brief.

In 2014, the era we’re in now on the time machine, forms gained a lot. HTML5 brought field types (email, tel, date), built-in validation and the autocomplete attribute, and phones learned to show the right keyboard. All of that used to be done with scripts. Now it’s built into the browser.

What a form is made of

<form action="/inquiry" method="post">
  <label for="f-name">What should we call you?</label>
  <input id="f-name" name="name" type="text" autocomplete="name" required>

  <label for="f-phone">Phone</label>
  <input id="f-phone" name="phone" type="tel" autocomplete="tel" required>

  <button type="submit">Book a consultation</button>
</form>

• <form> groups the fields. action says where to send the data, and method says how: get or post.
• <input> is a field. Its type sets the look and the validation, and its name is the name under which the value reaches the server. A field with no name is not sent.
• <textarea> is a multi-line field, and <select> is a choice from a list.
• <label> is a caption tied to a field: the label has for="f-name" and the field has id="f-name". Clicking the label puts the cursor in the field, and a screen reader names the field by its label.
• <button type="submit"> sends the form. Write the action on it (“Book”), not just “Send”.

Look at the diagram: the form on the left, and on the right the request the browser will build, with the messages from validation. Switch the method and the field type.

POST /inquiry HTTP/1.1
Host: riverbend.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 36

name=Anna&contact=anna%40example.org

GET and POST

GET puts the data in the address: /search?q=boundaries. That works well for a search: the result can be bookmarked and shared as a link. POST puts the data in the body of the request, not in the address. Inquiries, sign-ups and anything that changes something on a server are sent that way. A person’s phone number shouldn’t end up in the browser history or in the address bar.

And of course forms are served, and received, only over HTTPS, or the body of the request can be read on the way. You met this in the lesson on TLS.

How does the server know what to do with the data? We have no server yet, so we simply write action="/inquiry". In the part on servers you’ll see that a program stands behind that address. For static sites with no server of their own, there are ready-made form-handling services.

Field types, hints and validation

The type tells the browser what kind of data the field expects:

• type="tel" is a phone number: on a phone it opens the number pad;
• type="email" is an email address: the browser checks that there is an @;
• type="date", type="number", type="url" are a date, a number and a web address.

The autocomplete attribute says what kind of data is being asked for: name, tel, email, street-address. The browser fills in what it has saved, and the person completes the form in seconds. It is also an accessibility requirement: autofill helps most the people who find typing hard.

You switch validation on with attributes: required (the field is compulsory), minlength, pattern, min and max. The browser itself won’t let a wrong form go, and shows a message. For simple checks that is enough. But remember the main point: checking in the browser is a convenience, not protection. A request can be sent without going through your form, so the server always checks the data again.

Fewer fields, more inquiries

Every field is an obstacle. Ask only for what you can’t do without: to book, that’s a name and a way to reach the person, and the rest can be found out later. Don’t ask for what you already have. Don’t add a “title” or a “postcode” field where it isn’t needed.

Write a field’s label for a person, not for a database. “What should we call you?” is warmer than “Full name”. And on the button say what will happen: “Book a consultation”.

Consent and personal data

A name and a phone number are personal data: information that can identify a person. If you collect them, you are responsible for them. Under the EU’s General Data Protection Regulation (GDPR) and its UK twin, the UK GDPR, you are a “controller”. Which law applies depends on where your visitors are, not only on where you are: the GDPR also covers a business outside the EU that offers its services to people in the EU. In the United States there is no single federal law for ordinary websites. Instead there are state laws, such as California’s CCPA, as amended by the CPRA, and the FTC polices unfair or deceptive practices. The details are in part 15. In a form, the minimum is this:

• Know your lawful basis. The GDPR lists six (Article 6), and consent is only one of them. For an inquiry form, “steps at the request of the person before entering a contract” or “legitimate interests” can fit instead, and then no box is needed. What you always need is to tell people, at the point where you collect their details, who you are, what you do with them and for how long. That is your privacy notice, so link it from the form.
• When you do rely on consent, it has strict marks. It must be freely given, specific, informed and unambiguous, shown by a clear affirmative act (Article 4(11)). Recital 32 spells out that silence, pre-checked boxes and inactivity aren’t consent, so never use checked.
• Keep it separate and provable. A request for consent must stand apart from other terms (Article 7(2)), and you must be able to show that the person agreed (Article 7(1)). Anything extra, such as a newsletter, gets its own box, which must be optional (Article 7(4)).
• Make it easy to withdraw. The person can take consent back at any time, and doing so must be as easy as giving it (Article 7(3)). Say how in the notice.
• Serve the form over HTTPS.

Our practice form uses one required box that says the person agrees to their details being used to reply. That is the plainest pattern, and it works because without the details the form can’t do its job. In the US, most states ask for a notice at the point of collection rather than a checkbox for a form like this, and a few kinds of data, such as health or precise location, need opt-in in some states. Cookies and similar technologies have a rule of their own in the EU (the ePrivacy Directive) and the UK (PECR): consent before anything that isn’t strictly necessary. Russia’s law on personal data (152-FZ) goes further still, asking for consent that is separate from other terms and kept on record.

This is general information, not legal advice, and it was checked on 28 October 2026. Laws change and differ between places. For a real site, have a lawyer read your consent text and privacy notice, and ask the authority: the Information Commissioner’s Office (ICO) in the UK, your national data protection authority in the EU, and in the US your state attorney general or the FTC.

Practice

You’re starting the 2014 era. The page below looks like your 2005 one, but it’s a new version of the site (on the time machine, each era is built afresh). Add a form for your project’s main action.

If your main action is “call” or “read”, a form is still useful as a fallback: for someone who doesn’t like phoning, it lets them leave a number.

What was wrong with forms before

Fields were labeled with plain text beside them, checked only by scripts that didn’t work for some people, and the phone number was requested “in any format”. There were no consent boxes at all, and data was collected with no notice. Today the browser and the law ask for more. Both protect the person.