HTTP Methods- GET VS POST | W3Docs

HTTP (Hypertext Transfer Protocol) was created to provide communication between clients and a server. It operates on a request-response model: the client sends a request that specifies an HTTP method (also called an HTTP verb), and the method tells the server what kind of action to perform on the target resource.

An HTML <form> natively supports only two of these methods — GET and POST — through its method attribute. That is why these two are the ones most HTML developers meet first. But HTTP itself defines several more methods (PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT), which you reach through JavaScript (fetch) or your backend when building REST APIs.

Two Key Properties: Safe and Idempotent

Before looking at individual methods, two terms describe how each one behaves. They are used throughout this page and in HTTP specifications.

Safe — the method is read-only. It must not change the state of the server. Fetching a page should never create, update, or delete anything. GET, HEAD, and OPTIONS are safe.
Idempotent — making the same request once or many times has the same effect on the server. Sending one DELETE for a resource, or sending it five times, leaves the resource deleted either way. Safe methods are always idempotent, but a method can be idempotent without being safe (for example PUT and DELETE).

Here is how the common methods compare:

Method	Safe	Idempotent	Has request body	Typical use
GET	Yes	Yes	No	Retrieve a resource
HEAD	Yes	Yes	No	Retrieve headers only
OPTIONS	Yes	Yes	No	Discover allowed methods / CORS preflight
POST	No	No	Yes	Create a resource or submit data
PUT	No	Yes	Yes	Replace / update a resource at a known URL
PATCH	No	Not guaranteed	Yes	Apply a partial modification
DELETE	No	Yes	Usually no	Remove a resource

Info

PATCH is not guaranteed to be idempotent. Depending on how the patch is written, it can be (for example, "set status to active") or it can not be (for example, "increment the counter by 1"). The HTTP specification leaves this to the implementation.

GET Method

The GET method requests data from a specified source. It is safe and idempotent: it only reads data and never changes anything on the server. GET requests can be cached and remain in the browser history. They can also be bookmarked.

It should never be used for sensitive data, because the query string is part of the URL (which is logged, cached, and bookmarked). GET requests have practical length restrictions, and they should be used only to retrieve data.

Danger

The query strings (name/value pairs) are sent in the GET request's URL.

Example of an input type text with a get method

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="get">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br />
      <br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Try it Yourself »

POST Method

The POST method submits data to be processed to a specified source. It is neither safe nor idempotent: it can change server state, and submitting the same form twice usually creates two records — which is why browsers warn you before re-sending POST data. As opposed to the GET method, POST requests are never cached, do not remain in the browser history, and cannot be bookmarked. Moreover, POST requests are not subject to URL length restrictions, though servers typically enforce their own body size limits.

Danger

The query strings (name/value pairs) are sent in the POST request's HTTP message body.

Example of a form with the "post" method

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="post">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br /><br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Try it Yourself »

Comparison of GET and POST Methods

Feature	GET	POST
Back button/Reload	Harmless	Reloading the page will resubmit the form data. The browser must warn that the data will be re-submitted in this case.
Can be Bookmarked	Yes	No
Can be cached	Yes	No
Encoding Type	application/x-www-form-urlencoded	application/x-www-form-urlencoded or multipart/form-data
History	Remains in browser history.	Doesn't remain in browser history.
Data Length Restrictions	While sending data, GET method adds the data to the URL. The URL length is limited (maximum URL length is 2048 characters).	Doesn't have URL length restrictions, though servers typically enforce body size limits.
Data Type Restriction	Primarily ASCII characters, though UTF-8 is supported via percent-encoding.	Doesn't have restrictions. Binary data is also allowed.
Security	Less secure than POST, as the data sent is part of the URL.	POST is more secure than GET, as data is not visible in the URL or browser history. However, both transmit data in plaintext over HTTP and require HTTPS for actual security.
Visibility	Data is visible to everyone in the URL.	Doesn't show data in the URL.

Note The HTML <form> element natively supports only GET and POST through its method attribute. To use PUT, PATCH, or DELETE, you typically send the request with JavaScript (fetch) or let your backend framework override the method.

HEAD, OPTIONS, and CONNECT

Besides GET and POST, HTTP defines several other methods. Three of them are described here; the resource-oriented PUT, PATCH, and DELETE follow in their own sections.

Method	Safe	Idempotent	Description
HEAD	Yes	Yes	Identical to GET, but the server returns only the HTTP headers, not the response body.
OPTIONS	Yes	Yes	Asks the server which methods and options are available for a resource.
CONNECT	No	No	Establishes a tunnel to the server, used by proxies for HTTPS.

HEAD

HEAD works exactly like GET but the server omits the body and sends back only the headers. Because it is safe and idempotent, it is ideal when you need metadata without downloading the whole resource — for example, checking the Content-Length of a large file before downloading, or testing whether a URL is still reachable (its status code) without transferring its content.

OPTIONS

OPTIONS asks the server what it permits for a resource. The response usually includes an Allow header listing the supported methods (for example Allow: GET, POST, OPTIONS). Its most important real-world use is the CORS preflight request: before a browser sends a cross-origin PUT, DELETE, or a request with custom headers, it automatically fires an OPTIONS request to confirm the server allows the actual call. You rarely write OPTIONS requests by hand — the browser does it for you.

CONNECT

CONNECT tells a proxy server to establish a transparent TCP/IP tunnel to the destination, most commonly so that encrypted HTTPS traffic can pass through the proxy unread. It is used by infrastructure rather than application code, so you will almost never call it directly.

PUT Method

The PUT method is mostly used to replace or update a resource. The client sends the target resource URL together with a request body that contains the complete, updated representation of that resource. PUT can also create a resource when the client (not the server) decides the resource's URL.

PUT is not safe, because it changes state on the server, but it is idempotent: if you send the same PUT request twice, the resource ends up in exactly the same state as it would after one request — the body fully replaces whatever was there.

The example below asks the server to store the given JSON body as the resource at /users/42:

HTTP Methods - PUT request example

PUT /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Content-Length: 54

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

After storing the body, the server might respond like this:

HTTP Methods - PUT response example

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Content-Length: 54
Connection: keep-alive

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

PATCH Method

The PATCH method is used for partial modification of a resource. Unlike PUT, it does not need the whole resource — the body contains only the changes to apply.

PATCH is not safe, and it is not guaranteed to be idempotent: depending on the patch format, it may or may not produce the same result when repeated. A patch like "set status to active" is idempotent, but a patch like "add 1 to views" is not. Collisions between two PATCH requests can also be dangerous, because some patch formats expect to apply changes from a shared base state; otherwise the resource can be corrupted.

The example below changes only the email field of the user, leaving every other field untouched:

HTTP Methods - PATCH request example

PATCH /users/42 HTTP/1.1
Host: www.w3docs.com
Content-Type: application/json
Content-Length: 31

{ "email": "[email protected]" }

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Connection: keep-alive

DELETE Method

As the name suggests, this method removes the resource identified by a URL. DELETE is not safe but is idempotent: once a resource is deleted, calling DELETE again leaves it deleted — the end state is the same. (Repeated calls may return a different status code, such as 404 Not Found on the second attempt, but the server state does not change further.)

The example below asks the server to delete the user at /users/42:

DELETE request example

DELETE /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive

After deleting the resource, the server commonly responds with 204 No Content — a success status that carries no response body:

DELETE response example

HTTP/1.1 204 No Content
Date: Mon, 15 Jun 2026 14:53:57 GMT
Connection: keep-alive

A 200 OK (optionally with a body describing the deleted resource) is also a valid DELETE response. See HTTP status messages for the full list of status codes.