The method Attribute

In the last lesson you learned that action tells the browser where to send your form data. Now meet method, which answers a different question entirely.

Not where. How.

The method attribute controls the way the browser delivers your form data to the destination. There are two options and you will use both of them throughout your career. They are called GET and POST.

Let us understand both of them properly, from the ground up.

GET

GET is the default. If you write a form without any method attribute at all, the browser uses GET automatically.

When this form submits, something interesting happens in your browser's address bar. The URL changes to something like this.

Do you see what happened there? The data the user typed into the form got attached directly onto the URL. That little question mark is where the form data begins. Everything after it is called the query string, and it contains all the field names and values from your form, packed into the URL itself.

This is not a bug. This is exactly how GET is supposed to work.

When to use GET

GET is the right choice whenever the form is asking for information rather than sending information. Search bars are the perfect example. When you type something into Google and hit Search, Google uses GET. That is why you can copy the URL from your search results and paste it to a friend and they see the exact same results. The search is right there in the URL.

Use GET for things like search forms, filters, and sorting options. Basically any time submitting the form just asks a question and does not change anything.

What GET is NOT good for

Passwords. Credit card numbers. Private messages. Anything sensitive at all.

Because GET puts your data in the URL, it gets saved in the browser history, logged by web servers, and visible to anyone looking over your shoulder. You would never want a password showing up in a URL like this.

/login?email=john@email.com&password=mysecretpassword123

That would be a serious problem. For anything like that, you need POST.

POST

POST sends the data differently. Instead of attaching it to the URL, POST packages the data up and sends it in the background, invisible in the address bar.

When this form submits, the URL stays exactly as it is. Nothing gets added to it. The email and password travel separately, tucked away in what is called the request body, which is not visible to the user at all.

When to use POST

POST is the right choice whenever the form is sending something that should change or be stored. Login forms, registration forms, contact forms, payment forms, file uploads, anything where you are submitting real data that will be saved, processed, or acted on.

A good way to remember it is this. If submitting the form twice would cause a problem, use POST. Imagine submitting a payment form twice. That would charge the customer twice, which is obviously bad. POST is designed for that kind of form. If you try to refresh a page after a POST submission, the browser actually warns you and asks if you really want to resubmit, specifically to prevent accidental duplicates.

GET vs POST Side by Side

Here is a simple way to see the difference between the two in your head.

GET is like shouting your order across a restaurant. Everyone can hear it, it is quick, and it works fine for a cup of coffee. POST is like handing the waiter a sealed note. The message gets delivered privately and nobody else at the table can read it.

	GET	POST
Data location	In the URL	In the request body
Visible in browser history	Yes	No
Good for	Search, filters	Login, signup, contact forms
Safe for passwords	Never	Yes
Bookmarkable	Yes	No

The name Attribute

While we are here, this is a great moment to talk about something you may have noticed in the examples above. Every input has a name attribute.

You already know that id connects an input to its label. The name attribute does something different. It is the label that the browser uses when it actually packages up your form data to send it.

Think of it this way. When the form submits, the browser goes through every input and asks two things. What is the name of this field, and what did the user type into it. It bundles those pairs together and sends them to the server.

If you forget to add name to an input, that field gets completely ignored when the form submits. The data just disappears. It will not cause an error, it just silently gets left out, which can be very confusing to debug if you do not know about this.

So the rule is simple. Every input that you want to actually capture needs both an id and a name. The id is for the label connection and the browser's accessibility features. The name is for the form submission.

They can even be the same value, which is what most developers do to keep things simple.

A Complete Example

Here is a full login form using everything from this lesson and the last one. Read through it and see how action, method, name, and id are all working together.

Walk through what happens when someone fills this out and clicks Log In.

The browser looks at action and knows to send the data to /login. It looks at method and knows to send it via POST, meaning nothing appears in the URL. It picks up the name on each input and bundles the email and password together with their labels. The validation runs first because of required and minlength. If everything passes, the data goes off to the server.

That is a real login form. The same logic powers almost every login page on the internet.

Up next you are going to meet the <fieldset> and <legend> tags, which give you a clean way to group related inputs together inside a form.