Hmmm… should you use GET or POST as the method for your HTML forms? Neither! You should be using post, actually. While the world will keep on spinning no matter how you capitalize the word, all attribute values should really be lowercase for consistency.

This article will show you why you should never be submitting forms using the get method.

Solid Statement: Anytime you build a form tag, put post as the method. Get should be used for pulling information from the server, such as when creating a URL for a product page or a blog post. Imagine any URL you want to bookmark or share.

Never setup a way to alter data using get. It falls under the heading of most absurd design practices. A URL, no matter how it is formed, should only be used to fetch information from the server.

Some people might think that they are safe, just because they are processing a form in a manner that never shows the URL parameters, but that is wishful thinking. Not only is it semantically wrong to use get to alter the state of a system, but it’s only a matter of time before it bites you.

Following is a bullet list of the top reasons to use POST instead of get:

Why You Should Always Use the Post Method

  • There is a strict limit on the amount of data in a get request.
  • No changes inadvertently occur due to a URL being visited.
  • There can be character encoding issues with get values.
  • The form data doesn’t pollute the URL for the visitor.
  • Get data is cached- something you never want in forms.
  • If you used get, you can’t follow the PRG Pattern!
  • It is the proper semantic way to handle forms (duh).
  • Post handles file uploads (binary data).

A bullet list doesn’t always cut it, so here are a few more details for the discerning developer.

Data Limit– Some people scoff at the data limit thing, without considering that many forms send a bit more information that a few words and numbers.
Any form with a textarea or even a handful of text inputs can surpass the data length limit that a URL can hold. What’s worse is that browsers vary in that limit.

Caching– A get request is often cached. This is proper browser behavior, since it thinks it is helping you fetch information faster. A cached form submission will cause all sorts of disasters for you. Any browser history or bookmark will retain the parameters.

Encoding– A get request automatically URL encodes data. This makes your request larger than it has to be and can cause your submission to reach the data limit. Also, it only accepts ASCII characters. With post, your encoding remains how you want it.

PRG Pattern– This is the most important item. The PRG pattern (check out this form handling article) solves the problem of duplicate form submissions and allows the user to refresh the page at any time or use the back button without resubmitting data or getting those popup messages about resubmitting data.