What's the difference when using GET
or POST
method? Which one is more secure? What are (dis)advantages of each of them?
-
3Get doesn't have a body so in practice means you are limited to name -> value pairs as data structure due the lack of any query string encoding format for more complex structure. If you need to handle more complex data structures in your requests (i.e. an array, object etc) you need to use POST and perhaps more advanced formats(json/xml). Shortly said: don't use GET unless you really have to(i.e. the URL/resource must be discoverable). – themihai Jul 15 '16 at 17:29
-
1Possible duplicate of [When do you use POST and when do you use GET?](http://stackoverflow.com/questions/46585/when-do-you-use-post-and-when-do-you-use-get) – Imran Ali Khan Mar 02 '17 at 21:47
15 Answers
It's not a matter of security. The HTTP protocol defines GET-type requests as being idempotent, while POSTs may have side effects. In plain English, that means that GET is used for viewing something, without changing it, while POST is used for changing something. For example, a search page should use GET, while a form that changes your password should use POST.
Also, note that PHP confuses the concepts a bit. A POST request gets input from the query string and through the request body. A GET request just gets input from the query string. So a POST request is a superset of a GET request; you can use $_GET
in a POST request, and it may even make sense to have parameters with the same name in $_POST
and $_GET
that mean different things.
For example, let's say you have a form for editing an article. The article-id may be in the query string (and, so, available through $_GET['id']
), but let's say that you want to change the article-id. The new id may then be present in the request body ($_POST['id']
). OK, perhaps that's not the best example, but I hope it illustrates the difference between the two.
-
16There is definately a security aspect to the difference between GET and POSTs. A malicious site can stick an arbitrary GET request in an image tag for instance, causing users to do a GET against another server. If this GET is like http://otherserver/deletemyaccount then bad things happen. – Frank Schwieterman Feb 02 '09 at 22:28
-
3What I meant was that contents of $_POST is not magically hidden from malicious users. There are obviously security aspects to all thing programming. – troelskn Feb 02 '09 at 22:34
-
2This post doesn't answer the question completely because he doesn't mention of the security implications. The top part is good as long as the spelling error "pain English" is changed to "plain English". The bottom part is too hard to follow. On the whole, much better than my post tho. :-) – Akrikos Feb 03 '09 at 18:29
-
@FrankSchwieterman well if you make your GET-requests idempotent, which you should, that won't be a problem ;) – Linus Unnebäck May 28 '12 at 15:23
-
1" A POST request gets input from the query string and through the request body." IMHO this is incorrect. To use either input you need to use $_REQUEST. $_POST does not get the url entries. – Gunnar Bernstein Apr 21 '14 at 12:17
-
1@Frank Schwieterman I know this post is old, but delete my account is not idempotent and should not be using get. – frostymarvelous Aug 31 '14 at 18:55
-
Is `POST` a superset of `GET`? Or is there anything than can be done with `GET` that *cannot* be done with `POST`? – kevinarpe Nov 02 '15 at 07:03
-
@kevinarpe - from a technical perspective, you could say that `POST` is a superset of `GET`, in that it has a body component, which a `GET` doesn't. I don't think it makes too much sense to think of it that way though, since the two have very different semantics. A `GET` request is idempotent - e.g. it is cacheable and it's safe to re-issue. A `POST` has no such guarantees and is generally unsafe to re-issue. – troelskn Nov 03 '15 at 08:09
-
@troelskn: Good point about `GET` is idempotent, and thus eligible for caching. So it is a good idea not to think of `POST` as a superset of `GET`! – kevinarpe Nov 03 '15 at 11:30
-
Can you do a post request, without starting out by making a get request (from client side). Or are you somehow forced to make a get request first? – Lealo Aug 22 '17 at 18:20
-
@Lealo Yes, you can certainly make a POST without first making a GET. It's a core principle of HTTP that there is no continuity between requests. – troelskn Aug 22 '17 at 20:21
-
@FrankSchwieterman — A malicious site could create a form element with method=post and submit it with JavaScript. Making the correct choice between POST and GET does not save you from CSRF attacks. (It does save you from precachers and spiders though). – Quentin Dec 08 '17 at 15:44
-
If the endpoint accepts a file and return a line from the file (no data creation or changing or database is involved), then should the endpoint be GET or POST? – variable Dec 06 '19 at 06:08
When the user enters information in a form and clicks Submit , there are two ways the information can be sent from the browser to the server: in the URL, or within the body of the HTTP request.
The GET method, which was used in the example earlier, appends name/value pairs to the URL. Unfortunately, the length of a URL is limited, so this method only works if there are only a few parameters. The URL could be truncated if the form uses a large number of parameters, or if the parameters contain large amounts of data. Also, parameters passed on the URL are visible in the address field of the browser not the best place for a password to be displayed.
The alternative to the GET method is the POST method. This method packages the name/value pairs inside the body of the HTTP request, which makes for a cleaner URL and imposes no size limitations on the forms output. It is also more secure.

- 13,738
- 20
- 78
- 116

- 62,595
- 73
- 179
- 242
-
4because its harder to change? you can change GET in the address bar, but its not that easy with POST. – IAdapter Feb 02 '09 at 23:16
-
12The server can't trust the client. Designing your application around false assumptions, is far from secure. – troelskn Feb 02 '09 at 23:43
-
-
1I believe this is the most clear explanation -- difference about the placement of the data sent. Thank you. – greenoldman Jun 30 '11 at 06:02
-
The client can also make a get request with curl or ajax and write whatever he wants. – shinzou Sep 28 '17 at 20:37
The best answer was the first one.
You are using:
- GET when you want to retrieve data (GET DATA).
- POST when you want to send data (POST DATA).

- 487
- 5
- 2
-
2What is request/response service pattern is used and you want to do both? ;) I would prefer to use POST in most of the cases when I need to have a response back. – Dmitry Pavlov Dec 10 '13 at 15:15
-
11Generally that is true. `GET` is perfectly capable of 'sending' data too, so not a very accurate answer. – Patrick Hofman Jan 22 '15 at 14:41
There are two common "security" implications to using GET
. Since data appears in the URL string its possible someone looking over your shoulder at Address Bar/URL may be able to view something they should not be privy to such as a session cookie that could potentially be used to hijack your session. Keep in mind everyone has camera phones.
The other security implication of GET
has to do with GET
variables being logged to most web servers access log as part of the requesting URL. Depending on the situation, regulatory climate and general sensitivity of the data this can potentially raise concerns.
Some clients/firewalls/IDS systems may frown upon GET
requests containing an excessive amount of data and may therefore provide unreliable results.
POST
supports advanced functionality such as support for multi-part binary input used for file uploads to web servers.
POST
requires a content-length header which may increase the complexity of an application specific client implementation as the size of data submitted must be known in advance preventing a client request from being formed in an exclusively single-pass incremental mode. Perhaps a minor issue for those choosing to abuse HTTP
by using it as an RPC (Remote Procedure Call) transport.
Others have already done a good job in covering the semantic differences and the "when" part of this question.
I use GET when I'm retrieving information from a URL and POST when I'm sending information to a URL.

- 146,731
- 54
- 156
- 201
-
2but you can use GET to send as well. The difference is the format (in the url (GET) or in the request (POST)). – eric Aug 22 '17 at 01:39
-
1If the endpoint accepts a file and return a line from the file (no data creation or changing or database is involved), then should the endpoint be GET or POST? – variable Dec 06 '19 at 06:10
You should use POST if there is a lot of data, or sort-of sensitive information (really sensitive stuff needs a secure connection as well).
Use GET if you want people to be able to bookmark your page, because all the data is included with the bookmark.
Just be careful of people hitting REFRESH with the GET method, because the data will be sent again every time without warning the user (POST sometimes warns the user about resending data).

- 11,799
- 13
- 42
- 47
-
If the endpoint accepts a file and return a line from the file (no data creation or changing or database is involved), then should the endpoint be GET or POST? – variable Dec 06 '19 at 06:10
-
@variable POST. In this case, mostly because POST is built to handle file uploads and standard GET isn't. You'd have to send the file every time the page loads, so it makes sense to just use standard POST instead of GET+file which would break GET's expectation that a URL should give more-or-less the same results every time. – Grant Dec 10 '19 at 07:52
This W3C document explains the use of HTTP GET and POST.
I think it is an authoritative source.
The summary is (section 1.3 of the document):
- Use GET if the interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
- Use POST if:
- The interaction is more like an order, or
- The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
- The user be held accountable for the results of the interaction.

- 1,577
- 15
- 25
-
11I think that can be further summarized as this: GET when the state of the server isn't changed, POST when it is. – Yamcha Aug 11 '15 at 15:01
Get and Post methods have nothing to do with the server technology you are using, it works the same in php, asp.net or ruby. GET and POST are part of HTTP protocol. As mark noted, POST is more secure. POST forms are also not cached by the browser. POST is also used to transfer large quantities of data.

- 26,667
- 58
- 180
- 286
The reason for using POST when making changes to data:
- A web accelerator like Google Web Accelerator will click all (GET) links on a page and cache them. This is very bad if the links make changes to things.
- A browser caches GET requests so even if the user clicks the link it may not send a request to the server to execute the change.
- To protect your site/application against CSRF you must use POST. To completely secure your app you must then also generate a unique identifier on the server and send that along in the request.
Also, don't put sensitive information in the query string (only option with GET) because it shows up in the address bar, bookmarks and server logs.
Hopefully this explains why people say POST is 'secure'. If you are transmitting sensitive data you must use SSL.

- 12,419
- 7
- 54
- 59
GET
and POST
are HTTP methods which can achieve similar goals
GET
is basically for just getting (retrieving) data, A GET
should not have a body, so aside from cookies, the only place to pass info is in the URL and URLs are limited in length , GET
is less secure compared to POST
because data sent is part of the URL
Never use GET
when sending passwords, credit card or other sensitive information!, Data is visible to everyone in the URL, Can be cached data .
GET
is harmless when we are reloading or calling back button, it will be book marked, parameters remain in browser history, only ASCII characters allowed.
POST
may involve anything, like storing or updating data, or ordering a product, or sending e-mail. POST
method has a body.
POST
method is secured for passing sensitive and confidential information to server it will not visible in query parameters in URL and parameters are not saved in browser history. There are no restrictions on data length. When we are reloading the browser should alert the user that the data are about to be re-submitted. POST
method cannot be bookmarked

- 33,269
- 19
- 164
- 293

- 721
- 9
- 6
All or perhaps most of the answers in this question and in other questions on SO relating to GET
and POST
are misguided. They are technically correct and they explain the standards correctly, but in practice it's completely different. Let me explain:
GET
is considered to be idempotent, but it doesn't have to be. You can pass parameters in a GET
to a server script that makes permanent changes to data. Conversely, POST
is considered not idempotent, but you can POST
to a script that makes no changes to the server. So this is a false dichotomy and irrelevant in practice.
Further, it is a mistake to say that GET
cannot harm anything if reloaded - of course it can if the script it calls and the parameters it passes are making a permanent change (like deleting data for example). And so can POST
!
Now, we know that POST
is (by far) more secure because it doesn't expose the parameters being passed, and it is not cached. Plus you can pass more data with POST
and it also gives you a clean, non-confusing URL. And it does everything that GET
can do. So it is simply better. At least in production.
So in practice, when should you use GET
vs. POST
? I use GET
during development so I can see and tweak the parameters I am passing. I use it to quickly try different values (to test conditions for example) or even different parameters. I can do that without having to build a form and having to modify it if I need a different set of parameters. I simply edit the URL in my browser as needed.
Once development is done, or at least stable, I switch everything to POST
.
If you can think of any technical reason that this is incorrect, I would be very happy to learn.

- 1,233
- 7
- 30
- 52
- GET method is use to send the less sensitive data whereas POST method is use to send the sensitive data.
- Using the POST method you can send large amount of data compared to GET method.
- Data sent by GET method is visible in browser header bar whereas data send by POST method is invisible.

- 33,269
- 19
- 164
- 293
Use GET method if you want to retrieve the resources from URL. You could always see the last page if you hit the back button of your browser, and it could be bookmarked, so it is not as secure as POST method.
Use POST method if you want to 'submit' something to the URL. For example you want to create a google account and you may need to fill in all the detailed information, then you hit 'submit' button (POST method is called here), once you submit successfully, and try to hit back button of your browser, you will get error or a new blank form, instead of last page with filled form.

- 1,180
- 15
- 19
I find this list pretty helpful
GET
- GET requests can be cached
- GET requests remain in the browser history
- GET requests can be bookmarked
- GET requests should (almost) never be used when dealing with sensitive data
- GET requests have length restrictions
- GET requests should be used only to retrieve data
POST
- POST requests are not cached
- POST requests do not remain in the browser history
- POST requests cannot be bookmarked
- POST requests have no restrictions on data length

- 6,334
- 5
- 48
- 56
The GET
method:
It is used only for sending 256 character date
When using this method, the information can be seen on the browser
It is the default method used by forms
It is not so secured.
The POST
method:
It is used for sending unlimited data.
With this method, the information cannot be seen on the browser
You can explicitly mention the
POST
methodIt is more secured than the
GET
methodIt provides more advanced features

- 4,923
- 4
- 30
- 38
-
"It is used only for sending 256 character date" — not true. "When using this method, the information can be seen on the browser" — post data is also visible in browsers, it just isn't quite so obvious. "It provides more advanced features" — such as? – Quentin Sep 30 '12 at 19:58
-
This isn't a terribly useful answer. Incorrect information such as 'it is not so secured' and 'provides more advanced features', and other things mentioned by Quentin. – Andrew Barber Oct 08 '12 at 06:28