Forms in HTML

Where are we?

Let’s start by reviewing HTML form tags.

This lesson’s goals

By the end of this lesson, you should:

  • Know how browsers send form data to Web servers.
  • Know the difference between get and post.
  • Know what URL encoding does.
  • Know the basic attributes of the <form>, <input>, and <button> tags.

Form data flow

Remember HTTP? That’s the protocol that Web browsers and servers use to talk to each other.

There are various types of HTTP messages that browsers and servers send to each other. A common one is GET. This is usually how a browser asks a server for a page.

For example, suppose a user is looking at this page at

Articles list

Figure 1. Articles list

Here’s part of the HTML for the page:

  <li><a href="why-dogs-are-great.php">Why dogs are great</a></li>
  <li><a href="playing-with-dogs.php">Playing with dogs</a></li>

Figure 2. HTML for articles list

The user clicks the link “Playing with dogs.” The browser contacts the server at, and sends:

GET /articles/playing-with-dogs.php HTTP/1.1

The server sends back the HTML for playing-with-dogs.php to the browser.

When the browser sends a message like GET to the server, the browser sends other data as well, besides the URL. For example, it tells the server what type of browser it is.

GET /articles/playing-with-dogs.php HTTP/1.1
User-Agent: Mozilla/5.0

Host and User-Agent are headers. Each one is on a different line.

There are many header types besides Host and User-Agent. They specify the date and time the request was sent, languages the browser would prefer, and other stuff. A typical GET might have a half dozen headers.

Here’s the important bit for this chapter: the total HTTP request – the URL and the headers – can include data the user typed into form fields. This gives a way for browsers to send data to servers (usually it’s the other way around).

When the user submits a form in a Web browser, the form data travels along with a URL.

Form data attached to URL

Figure 3. Form data attached to URL

So, the form data is sent along with a URL. But which URL? What page does the browser send the data to?

The browser sends form data to a page that is specially written to handle form data. The page knows how to extract the data, and do something with it, like save it to a database. That’s one of the things you do in PHP: write pages that can handle form data.

More on that later. Right now, we’re just looking at the form.

A form example

Let’s create a form like this:

Simple form

Figure 4. Simple form

There are two text fields, and a button. Clicking the button submits the form. This means that the browser sends the form’s data to the server.

Here’s the HTML:

<h1>Simple Form</h1>
<form action="process-simple-form-get.php" method="get">
  <p>First name:
    <input name="first_name" type="text" size="20">
    <input name="surname" type="text" size="20">
    <button type="submit">Save</button>

Figure 5. Simple form HTML

The form is wrapped in a <form> tag. This one has two attributes: action and method. There are other attributes we could use, but we don’t care about them yet.

The action says where the data should be sent. Remember that form data gets attached to a URL. This is the URL the data gets attached to.

The method attribute says how the form data will be attached. There are two ways: get and post.

The get method

get tacks the form data on to the URL itself. Suppose the user filled in the form like this:

Simple form with data

Figure 6. Simple form with data

The browser would create this URL:


Why this URL? Let’s look at the HTML again.

<h1>Simple Form</h1>
<form action="process-simple-form-get.php" method="get">
  <p>First name:
    <input name="first_name" type="text" size="20">
    <input name="surname" type="text" size="20">
    <button type="submit">Save</button>

Figure 5 (again). Simple form HTML

The main part of the URL is in the form’s action property: process-simple-form.php. The browser adds a ? on the end, to indicate the start of the form data.

Then it adds the data in form fields. There’s the name of a field, an equals sign (=), and the field data. An ampersand (&) separates the fields.

So we end up with:

Get action

Figure 7. Get action

Try it. Notice that you can see the data in the address field of your browser.

Address bar for get

Figure 8. Address bar for get

The post action

Instead of the get action:

<form action=... method="get">

you can use post:

<form action=... method="post">

It works almost the same as get, except that the form data is passed through in an HTTP header, rather than concatenated to the URL. So the message from the browser to the server might look like this:

POST /articles/playing-with-dogs.php HTTP/1.1
User-Agent: Mozilla/5.0
Content-Length: 32
Content-Type: application/x-www-form-urlencoded


Figure 9. post message example

The form data itself has the same pattern; field name then value, field name then value, etc.

The advantage of the post method is that the data doesn’t show up in the browser’s address bar:

Address bar for post

Figure 10. Address bar for post

Only the URL shows. Headers do not.

You can try it. You won’t see the form data in the address bar of your browser.

Most Webers use method="post" because the form data doesn’t show up in the browser’s address bar. It’s a little more secure, and less annoying.

Exercise: Address form

Create a form like this:

Address form

Figure 1. Address form

Use the get method. Set the action to the page itself. For example, if you called the file ralph-the-wonder-form.html, use action="ralph-the-wonder-form.html".

When the form is filled in, it should look something like this:

Address form with data

Figure 2. Address form with data

Have a look at how the browser attaches data to the URL.

You can see my solution, but try it yourself first.

Upload your solution to your server. Put the URL below.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

URL encoding and character sets

Let’s do an experiment. Open the get version of the form. Try typing some special characters into the form. A special character is anything that is not a letter or a digit. For example:

Special characters in a form

Figure 11. Special characters in a form

Click the button, and look at the URL on the form processing page. You’ll see something like this:


Some of the characters have been changed. The spaces became plus signs (+). The comma (,) became %2C.

This is called “URL encoding.” Browsers automatically URL encode data before sending it in a get or a post.

Why do browsers do this? URLs use a small character set. A “character set” is a limited group of characters to choose from. For example, when computers were first developed, most used the old US-ASCII character set. It has just the letters A to Z, the digits, punctuation(,.!; etc.) and a few other things. If you wanted to send characters with accents (like é) or currency symbols (like ¥), you were out of luck.

Other character sets were developed. Perhaps the most common international character set these days is UTF-8. It can represent thousands of characters; Cyrillic, Kanji, you name it, it’s probably in UTF-8.

The trouble is, URLs still use US-ASCII. It’s efficient, and is universally supported. So how do you send special characters in a URL?

The answer: URL encoding. It converts some special characters to a code. For example, it changes commas (,) into %2C. It also changes spaces into plus signs.

Browsers are not consistent in their URL encoding. Here’s how different browsers encode the data in Figure 11:


Internet Explorer



Only IE and Safari are the same.

Usually, you won’t need to worry about URL encoding. It happens automatically. But sometimes you’ll need to do it yourself in PHP. More on that later.

Exercise: Special characters in the address form

Open the page you created for the address form exercise. Type special characters into the fields. See how they are encoded in the URL generated by the form.

Make some notes below on how different characters (like %, $, +, and #) are encoded.

(Log in to enter your solution to this exercise.)

Can't find the 'comment' module! Was it selected?

Text input fields

Let’s go back and look at the HTML for the text input fields.

<h1>Simple Form</h1>
<form action="process-simple-form-get.php" method="get">
  <p>First name:
    <input name="first_name" type="text" size="20">
    <input name="surname" type="text" size="20">
    <button type="submit">Save</button>

Figure 5 (again). Simple form HTML

Line 4 sets up the first name field. <input> says it’s an input field. There are several types of input fields. Let’s stick with type="text" for now.

size sets the width of the field in number of characters. It does not limit the number of characters the user can type; size just affects the width of the field on the screen.

name is an important one. It’s the name given to the value when the data is sent to the server. You can see it in action on the last line of Figure 9.

The button

Nothing happens until the user hits the button. The HTML for our button is:

<button type="submit">Save</button>

Notice the type attribute. Earlier, we’ve seen this as type="button". When type="submit", the browser sends form data to the server when the button is pressed.


In this lesson, you learned:

  • Browsers send form data to Web servers along with URLs.
  • get attaches form data to a URL. post puts it in a separate HTTP header.
  • URL encoding handles special characters in URLs.
  • The basic attributes of <form> are action and method.
  • The basic attributes of <input> are type, name, and size.
  • The basic attribute of <button> is type.

What now?

Let’s see how you can write PHP to handle form data.