What a form does

What a form does

Understand how a form collects named values and turns a user action into an HTTP request the server can process.

A form does one thing. It collects named values and turns them into an HTTP request. The page collects. The browser sends. The server decides what to accept.

Everything else in this course builds on that idea, so let’s start with a form that works without any JavaScript:

<form action="/subscribe" method="post">
  <label for="email">Email address</label>
  <input id="email" name="email" type="email" required>
  <button type="submit">Subscribe</button>
</form>

When you click Subscribe, the browser looks at the controls inside the form and collects the ones that count. Here it finds one named value: [email protected].

Then it builds a request. action says where to send it, /subscribe. method says how, with POST. The values travel in the request body.

What each attribute does

Four attributes on that input look similar but have different jobs:

  • id connects the input to its label
  • name creates the key the server receives
  • type tells the browser what kind of value to expect, so it can pick a keyboard and check the format
  • required stops the browser from submitting an empty value

The one people mix up is name. An input without a name still shows up on the page. You can type in it. But the browser leaves it out of the request. The server never sees it.

I’ve debugged this more than once. The form looks fine, the request arrives, and one field is missing. The cause is a missing name.

The server still decides

The browser did its part. It refused an empty value and checked that the text looks like an email address. That is user feedback, nothing more.

The server at /subscribe still has to parse the body, check the value again, and only then store it or send an email. Anyone can send a POST to /subscribe without ever opening your page. We’ll come back to this in every module.

See the real output

The request is the real output of the form, so let’s look at it. Open DevTools, switch to the Network panel, and submit the form.

Click the request to /subscribe. You’ll see the method (POST), the URL, and a payload section showing email: [email protected]. The request headers include Content-Type: application/x-www-form-urlencoded, the default encoding for a form.

Now remove the name attribute from the input, reload, and submit again. The request still goes out, but the payload is empty. That one experiment explains most “the form doesn’t work” bugs I’ve seen.

Lesson completed