What changes when an HTML <form> uses method="get" instead of method="post", and how do you choose between them?

## Same entries, different destination Whichever method you pick, the browser first constructs the same entry list of name/value pairs from the named, enabled controls. `method` decides only how that list travels. **GET.** The list is percent-encoded as `name=value` pairs joined by `&` and becomes the query component of the action URL. The browser then navigates there. ```html <form action="/search" method="get"> <input type="search" name="q"> <button>Search</button> </form> ``` Submitting with `q=forms` requests `/search?q=forms`. **POST.** The list is placed in the request body, encoded according to `enctype`, and the URL stays exactly as written in `action`. ## The gotcha: GET discards the action's existing query This one bites nearly everyone once. Given `action="/search?page=2"`, a GET submission does **not** append to the existing query — it replaces the whole query with the serialized entry list, so the request is `/search?q=forms` and `page=2` is gone. The fix is to make the parameter part of the form: ```html <form action="/search" method="get"> <input type="hidden" name="page" value="2"> <input type="search" name="q"> </form> ``` POST does not have this problem: the action URL, query and all, is used verbatim, and the entries ride in the body. ## What each one buys you GET's real property is that **the resulting page is fully described by its URL**. That makes it shareable, bookmarkable, addressable by a link, and cacheable; the back and forward buttons move through result pages sensibly, and a reload just re-runs a read. This is exactly what you want for search, filtering, sorting and pagination — the form is a way of composing a URL. POST's properties are the mirror image. Values are not in the URL, so they do not land in bookmarks, browser history, or the referrer sent to third-party resources on the next page. There is no practical length ceiling from URL limits. And crucially, only POST can carry a body, which is what makes `enctype="multipart/form-data"` — and therefore file uploads — possible. Reloading the resulting page makes the browser warn before resubmitting, a friction that is appropriate when the submission changed something. Setting `enctype` on a GET form does nothing at all; there is no body to encode. ## The decision rule Use GET when the submission *reads* — it should be safe to repeat, and repeating it must have no side effects. Use POST when the submission *writes*: creating, updating, deleting, sending money, logging in. The rule is about the effect, not about sensitivity: putting a password in a GET form is bad because it lands in history and logs, but even a harmless write belongs in POST, because things that repeat safely and things that do not should not look the same to the browser, to a link prefetcher, or to a user who hits reload. A practical corollary for state-changing forms is the post/redirect/get pattern: handle the POST, then redirect to a GET-addressable result page, so the user's reload re-runs a read instead of the write. ## Related markup you should know - A submit button can override the form for its own activation with `formmethod`, so one button in a GET search form can POST to a different endpoint. - `method` and `action` are readable from script as `form.method` and `form.action`, which is how you reuse the markup's intent when you take submission over with `fetch`. - Whatever you choose, the method is a hint about intent, not a security boundary. A POST body is exactly as forgeable as a query string; both are user input and both must be validated server-side. ## Common misreadings "POST is encrypted" is false — only HTTPS encrypts anything, and it encrypts the URL of a GET request too. "GET has a 255-character limit" is folklore; there is no limit in the markup, only practical ceilings imposed by browsers, servers and proxies, which is a reason to prefer POST for large payloads but not a fixed number to quote.