/ HTTP Headers


The Accept-Patch HTTP response header is a vital component of the HTTP/1.1 protocol. Its primary role is to specify the patch document formats accepted by the server. The patch document formats, typically expressed as media types, are instrumental in modifying resources via PATCH requests. In this article, we’ll delve into the details of this header and its practical application.

Understanding the Accept-Patch Header

The Accept-Patch header is exclusively used in response messages and not in requests. Introduced as part of the HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV), this header is most commonly seen in 2xx (Successful) and 415 (Unsupported Media Type) responses.

A typical representation of this header is:

Accept-Patch: text/example;charset=utf-8

The value of the Accept-Patch header represents the Media Type(s) that the server is willing to accept for patch data. Here, text/example;charset=utf-8 indicates that the server accepts patches in the text/example format with utf-8 character encoding.

HTTP Request and Response with Accept-Patch

To understand how Accept-Patch works, consider the following HTTP interaction.

A client may send a GET request to the server:

GET /resource/123 HTTP/1.1
Host: www.example.com

The server can then respond with the details of the resource, including the Accept-Patch header to indicate the patch document formats that it will accept:

HTTP/1.1 200 OK
Content-Type: application/json
Accept-Patch: application/json-patch+json

  "id": "123",
  "name": "John Doe",
  "email": "john@example.com"

In this case, the Accept-Patch header indicates that the server accepts JSON Patch documents for modifying the resource.

When the client wants to modify the resource, it sends a PATCH request using the format specified by the Accept-Patch header:

PATCH /resource/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json-patch+json

  { "op": "replace", "path": "/email", "value": "john.doe@example.com" }

Here, the client sends a JSON Patch document that specifies a modification to the “email” field of the resource.

Note on Usage

While Accept-Patch is a valuable tool for communicating server-side constraints, it’s essential to remember that it’s not mandatory in all HTTP responses. Its usage is particularly relevant for resources that support the PATCH method. Additionally, clients must check the Accept-Patch header before sending a PATCH request to ensure the request adheres to the acceptable formats.


In summary, the Accept-Patch HTTP header plays a crucial role in defining the patch document formats a server can process. While its usage is not universal, it’s particularly vital for resources that allow modifications via PATCH requests. The correct usage of Accept-Patch can significantly streamline HTTP communication by clarifying server expectations, thereby reducing the chances of unnecessary 415 (Unsupported Media Type) responses. As a developer, understanding and correctly implementing this HTTP header is a valuable skill for building robust and interoperable web services.

Was this helpful?

Thanks for your feedback!