GET vs POST is the choice that decides whether a form’s answers stay in the link. With GET, the browser adds them to the address. With POST, the same answers travel in the body of the request, and the address bar stays clean.
A contact form, a quote request, or a “tell us the date” box only shows the visitor a button. The method on that form decides whether their note becomes part of a URL.
GET Writes the Answers Into the Link
MDN’s guide to sending form data uses a small example: two fields, say set to Hi and to set to Mom, with method="GET". Submit it and the address becomes https://www.example.com/?say=Hi&to=Mom.
GET writes the answers into the link. After the ?, each name and value is joined with &. The browser is asking for a page, the form’s answers ride along in that address, and the request body is empty.
Two defaults make this easy to ship by accident. If the form has no action, the data goes to the URL of the page the form is on. If method is missing, or the value is not a valid one, the HTML standard assumes GET, so a form that “just works” in the browser can be a GET form you never chose.
POST Leaves the Address Bar Alone
The same two fields with method="POST" do not extend the URL. MDN shows the request as a short body, say=Hi&to=Mom, under headers that say the body is form data. The address stays https://www.example.com/.
POST sends the same answers in the request body. The visitor does not see them in the address bar, and a copied link does not carry the note.
The server still receives the names and values. The difference is where they traveled.
MDN is direct about the private case: if you need to send a password, or any other sensitive piece of data, do not use GET. You would be displaying it in the address bar.
The same page notes a practical limit. Some browsers and many servers cap how long a URL can be, so a long message is a poor fit for GET even when it is not private.
An upload breaks GET outright. File contents cannot live in a URL. The form needs POST, and enctype="multipart/form-data", or the upload has nowhere to go.
<form action="/contact-us/" method="post">
<label for="note">What do you need?</label>
<textarea id="note" name="note"></textarea>
<button>Send</button>
</form>That snippet is the whole lesson. method="post" is what keeps the textarea out of the address. Leave the attribute off, and the standard’s assumption is GET.
A Contact Form Is Not a Search
GET is a reasonable method when the answers are a search the visitor might want to repeat or share. A filter for “open Saturday” can live in the URL. A customer’s phone number, a job address, or a note about a leak should not.
Picture the quote form on a plumber’s site: the visitor types a street in Grant Park and a sentence about the water heater, then hits Send. With GET, that sentence is now in the address bar, in the browser history, and in any link they forward to a spouse. A private note does not belong in the address bar.
Form layout still matters: labels, order, the one button that means send. Method is the part that happens after the click, and it is invisible until you look at the URL.
This is also not the same question as what runs before a page loads. Middleware can redirect. The form method decides what the send button puts on the wire.
The Send Button Builds a Request
Open your own contact form, type a test sentence, and send it. If the address bar grows a ? and your sentence, the form is using GET. If the address stays put, the form is using POST, or a script sent the data without a full navigation.
Either way you can see it. You do not need a framework to check.
The fix, when the note should stay private, is the attribute: method="post", and an action that points at a page or endpoint that can receive it. GET remains the right tool when the result is a link someone should be able to open again.
If the form on the live site is how jobs arrive, that request is part of the product. We build that kind of site on our website design page.
Bring the form URL and what a customer is allowed to type. Fifteen minutes on the calendar is enough to say whether the send button is leaving their message in the link.
