How a Form Works

Every time you search a site, sign up for something or send a message through a web page, you are using a form. A form is the part of HTML that asks a person for information and sends their answers somewhere. The browser handles most of that work for you. One part it cannot do at all, and you need to know which before you build a form of your own.

Think of a paper form handed in at a counter. The printed questions and boxes are the form; someone behind the counter still has to read it and act on it. On the web, the HTML is the paper, and the person behind the counter is a program on a server. The rest of this page is about both halves, and about what happens when the second one is missing.

What Does a Form Actually Send?

A form is a form element with fields inside it: text boxes, checkboxes, and a button that sends it. Each field has a name attribute. When the form is submitted, meaning sent, the browser collects every named field and turns it into a pair: the field's name, an equals sign, and whatever the visitor typed. Pairs are joined with an ampersand, and spaces are written as plus signs.

<form action="https://duckduckgo.com/" method="get">
  <label for="search">Search the web</label>
  <input type="search" id="search" name="q">
  <button type="submit">Search</button>
</form>

This form has one field, named q, and one button. Put it in any page, type css grid into the box and press the button. The browser leaves your page and opens the search engine's results for css grid. The address bar now shows exactly what the form sent.

https://duckduckgo.com/?q=css+grid

Everything after the question mark is the form's data: one pair, the name q and the words you typed. The search engine reads it because q is the name it was built to expect. Your form had to use the receiver's name, the same way a paper form only works if you write in the boxes the office actually reads.

The label element names the field for people, and the next topic covers it properly. Notice for now that it plays no part in what is sent. Neither does the id, which exists so the label can point at its field.

Now the most common first form bug. Delete the name attribute from the input and try again. The browser still goes to the search engine, but it arrives with no words at all, and the search engine shows its empty start page. No error appears anywhere, in the page or in the Console.

<input type="search" id="search">

A field without a name is simply left out of the data. The browser does not warn you, because a nameless field is allowed: sometimes a page wants a field only for its own script. So when a form arrives with something missing, the name attributes are the first place to look.

Where and How: action and method

Two attributes on the form element decide where the pairs go and how they travel. The action attribute is the address that receives them. The method attribute is how they are carried, and it has two useful values, GET and POST. They are the two most common kinds of request, the message from Chapter 1 that a browser sends to a server: a GET asks for something, a POST delivers something. APIs for Beginners sends both by hand if you want to see them up close.

With method="get", the pairs are added to the address after a question mark, as in the search above. That is right for a search: the results have an address you can bookmark, share or return to with the Back button. It is wrong for anything private, because that address is saved in the browser's history, shown on screen, and often written into the logs of the server that receives it.

With method="post", the pairs travel inside the request itself, in a part called the body, and the address stays clean. That is right for a message, a sign-up or an order: anything that sends something rather than asks for something. POST is not a lock, though. What protects the data on its way is HTTPS, the secure connection used by every address that starts with https.

Leave both attributes out and the form uses GET and sends the pairs to the page it is already on. That default is why a form written in a hurry reloads its own page, with the visitor's words sitting in the address bar.

You can watch either kind of request in DevTools. Open the Network panel, submit the form, and click the request at the top of the list. For a GET, the pairs are in the address. For a POST, open the request's Payload tab: the names and values are listed there instead.

Who Receives the Form?

The browser's part ends at sending. The action address has to lead to a server running a program that waits for requests like this one, reads the pairs, and does something with them. It might save a message, send an email, or look up search results. The search engine in the example has such a program. Your site, so far, does not.

The site you are building is static: a folder of files that a server hands out exactly as they are. A static server can send contact.html to anyone who asks, but nothing on it listens for a form's answers or knows what to do with them. Send a form to such a site and, at best, the visitor sees an error page. At worst the page quietly reloads, and they believe their message was sent.

Writing that receiving program is backend work, and it is what Backend Deep Dive teaches. This book stays on the browser's side of the counter. Topic 4 of this chapter shows what the site's contact form can honestly do without a server of its own.

What Does a Real Form Give You for Free?

Using a real form element, rather than a few loose fields and a script, earns several things without a line of code. Pressing Enter in a text field submits the form, which keyboard users rely on. The browser offers entries the visitor typed before into similar fields. Password managers recognise a sign-in form and fill it in.

A form also works before any JavaScript arrives, and after JavaScript fails. That is the book's order again: HTML that works on its own first, then the look, then the behaviour. The last topic of this chapter adds a script on top of a form without giving up any of this.