HTTP PUT Request Method

The HTTP PUT method is used to update an existing resource on the server, while the POST method creates or adds a resource on the server. Unlike GET and HEAD requests, the HTTP PUT request may change the server state.

You can send data to the server in the body of the HTTP PUT request. The type and size of data are not limited. But you must specify the data type in the Content-Type header and the data size in the Content-Length header fields. You can also post data to the server using URL parameters with a PUT request. In this case, you are limited to the maximum size of the URL, which is about 2000 characters (depends on the browser).

The HTTP PUT method is defined as idempotent, which means that multiple identical HTTP PUT requests should have the same effect as a single request.

HTTP PUT Example

The following example demonstrates making an HTTP PUT request to the server. In this example, the 'Content-Type: application/json' request header indicates the media type of the resource, and the 'Content-Length: 85' request header indicates the size of the data in the HTTP PUT request body.

HTTP PUT Request Example Run Example
PUT /echo/put/json HTTP/1.1
Authorization: Bearer mt0dgHmLJMVQhvjpNXDyA83vA_PxH23Y
Accept: application/json
Content-Type: application/json
Content-Length: 85

  "Id": 12345,
  "Customer": "John Smith",
  "Quantity": 1,
  "Price": 10.00

And the server response:

Server Response to HTTP PUT Request
HTTP/1.1 200 OK
Content-Length: 19
Content-Type: application/json


HTTP PUT Response Codes

If a new resource is created, the origin server MUST inform the client with a 201 (Created) status code. If an existing resource has been modified, status codes 200 (OK) or 204 (No Content) SHOULD be returned to indicate to the client that the request was successful. If the resource cannot be created or modified, an appropriate error code MUST be returned that reflects the nature of the problem (usually 500x).

Some notes on HTTP PUT requests:
  • PUT requests are never cached
  • PUT requests do not remain in the browser history
  • PUT requests cannot be bookmarked


Browser BACK button/Reload Harmless Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)
Bookmarked Can be bookmarked Cannot be bookmarked
Cached Can be cached Not cached
History Parameters remain in browser history Parameters are not saved in browser history
Restrictions on data length Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters) No restrictions
Restrictions on data type Only ASCII characters allowed No restrictions. Binary data is also allowed
Security GET is less secure compared to PUT because data sent is part of the URL

Never use GET when sending passwords or other sensitive information!
Visibility Data is visible to everyone in the URL Data is not displayed in the URL


The fundamental difference between the HTTP PUT and POST requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. In contrast; the URI in a PUT request identifies the entity enclosed with the request. Practically speaking, POST is used to append a resource to an existing collection, while PUT is used to update an existing resource.

See also

Last updated: Viewed: 8932 times