Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

HTTP PATCH is a method for asking a server to apply changes described in a patch document to the resource identified by the request URI. Unlike PUT, which sends a representation intended to replace the stored one, PATCH sends instructions for changing the current resource. The server and resource determine which patch-document formats are accepted.

How an HTTP PATCH request works

A PATCH request has the same general shape as other HTTP requests: a method, a target URI, headers, and—usually—a body. The body is not automatically “some JSON to merge.” It is a patch document whose format is identified by its media type, normally in the Content-Type header. The server interprets that document according to the format it supports and the semantics of the target resource.

For example, a server might accept a JSON Patch document with Content-Type: application/json-patch+json. Another server might accept a different patch format, or not support PATCH for that resource at all. RFC 5789 does not prescribe one universal format, and the fact that an endpoint accepts JSON does not by itself mean it accepts JSON Patch.

PATCH describes intended changes, not necessarily a small request. A patch document can contain multiple operations, and PATCH can have side effects on resources beyond the one named by the request URI. Whether it can create a resource that does not yet exist depends on the patch format, server behavior, and permissions.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

PATCH vs. PUT

Question PATCH PUT
What is in the request body? Instructions for changing the current resource, in a supported patch-document format. A representation intended to replace the target resource’s stored representation.
When is it a fit? When making a partial change and the resource supports the chosen patch format. When asking the server to replace the target representation with the enclosed representation.
Is the method idempotent? Not inherently. A particular patch can be designed to be idempotent. Yes, by HTTP method semantics.
What format is required? The patch document’s media type must match a format accepted by the resource. The enclosed content is the proposed replacement representation; handling depends on the resource’s representation format.

Idempotency means that repeating a request has the same intended effect on the server as making it once; it does not mean the server cannot record incidental events such as logs. Do not choose PATCH solely because a request body is short, or PUT solely because the body is JSON. Choose according to whether the operation means “apply these changes” or “replace this representation,” and check what the endpoint supports.

Example: send a JSON Patch document

JSON Patch, defined by RFC 6902, is one patch-document format. It represents an ordered sequence of operations on a JSON document. Here is an illustrative request that replaces a value at the JSON Pointer /status:

curl -X PATCH "$RESOURCE_URL" 
  -H "Authorization: Bearer $API_TOKEN" 
  -H "Content-Type: application/json-patch+json" 
  -H "Accept: application/json" 
  --data '[{"op":"replace","path":"/status","value":"active"}]'

Set RESOURCE_URL to the actual resource URL and API_TOKEN to credentials accepted by that service. This request is valid only if the target accepts JSON Patch, the resource has a replaceable /status value, and the credentials authorize the change. The operation names and paths are not generic HTTP behavior; they belong to JSON Patch and the target document’s structure. A server may return a success status with a representation, or success without one, depending on its implementation and the request.

JSON Patch operations are evaluated in order. If an operation cannot be evaluated, the patch document is not considered successfully applied. Combined with HTTP PATCH’s atomicity requirement, the server must not leave only the earlier operations applied. JSON Patch is a format used with PATCH, not a synonym for the method.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Make PATCH safe against stale updates

PATCH is not inherently safe or idempotent. For example, an instruction to increment a value can produce a different result if submitted twice. A client should not automatically retry a non-idempotent request after an uncertain network failure unless it knows the operation is idempotent or can determine that the first attempt was not applied.

Concurrency creates a separate risk: another client could change the resource after it was read but before the patch arrives. If the patch assumes a known base version, RFC 5789 recommends a conditional request. A common approach is to use a strong ETag received with the resource and send it in If-Match:

curl -X PATCH "$RESOURCE_URL" 
  -H "Authorization: Bearer $API_TOKEN" 
  -H "Content-Type: application/json-patch+json" 
  -H "If-Match: "$STRONG_ETAG"" 
  --data '[{"op":"replace","path":"/status","value":"active"}]'

Replace $STRONG_ETAG with the exact strong ETag supplied by the server. If the resource has changed and the validator no longer matches, the server can reject the update rather than applying it to a version different from the one the client intended. The application should then fetch the current representation, re-evaluate the change, and decide whether to submit a new patch. Do not blindly resend the same request after a timeout: the server may have completed it even if the response did not reach the client.

Check whether a resource supports PATCH

Support is not universal. A client can send an OPTIONS request for the resource and inspect the response’s Allow header for PATCH. For a resource that supports PATCH, RFC 5789 says an OPTIONS response should include Accept-Patch, listing supported patch-document media types. An Accept-Patch header in a response to another method also implicitly indicates that PATCH is allowed for that resource.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
curl -i -X OPTIONS "$RESOURCE_URL"

Read the response headers rather than assuming a format based on examples from another API. If there is no useful capability information, consult that service’s endpoint documentation. Even when the server advertises a media type, a particular patch can still fail because its document is malformed, its operations do not apply to the current resource, or the caller lacks permission.

Rank #4
Sale
HTTP: The Definitive Guide
  • Used Book in Good Condition

Atomicity: a patch applies all or none

RFC 5789 requires the server to apply the entire set of changes atomically. In other words, if any part of the patch cannot be applied, the server must not leave a partial result. The specification says: “The server MUST apply the entire set of changes atomically and never provide (e.g., in response to a GET during this operation) a partially modified representation.” This matters for multi-operation patches: a client should not need to guess which subset of a rejected patch was committed.

Atomicity is not the same as a guarantee that every PATCH succeeds, that the server will never fail, or that unrelated side effects are rolled back. It governs application of the patch’s changes to the target resource. The particular failure response depends on the problem and the patch format.

Common PATCH errors and what to do

  • 400 Bad Request: The patch document may be malformed or invalid for its format. Validate its syntax, required fields, operation names, and paths before sending it.
  • 415 Unsupported Media Type: The server may not support the format named in Content-Type for this resource. Check the endpoint’s documented formats or its Accept-Patch response header; RFC 5789 says a 415 response should include Accept-Patch to identify accepted formats.
  • 409 Conflict: The update may conflict with the resource’s state, or the server may be unable to queue concurrent requests to modify it. Fetch the latest version, resolve the conflict, and use a conditional request where appropriate.
  • A success response but unexpected data: Check the format’s semantics, target path, and the resource’s documented behavior. PATCH does not mean “merge arbitrary JSON” unless that endpoint defines such behavior.
  • Timeout or connection loss: The outcome may be unknown. Before retrying, determine whether the operation is idempotent or check the current resource state. Use version conditions where possible to avoid applying a stale change.
  • 405 Method Not Allowed or PATCH absent from Allow: The resource may not support PATCH. Use a supported method or endpoint; do not assume another route has identical update semantics.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Choose a patch format based on the endpoint

There is no universally best patch format established by the HTTP specifications. The server’s capabilities and the resource’s semantics control the choice. Before implementing a client, establish:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  1. Which media types the target resource accepts for PATCH.
  2. What operations the selected format defines, including how it handles missing paths, invalid operations, and operation ordering.
  3. Whether the update assumes a particular resource version and should include a strong ETag in If-Match.
  4. Whether the task is truly a partial modification; use PUT when the intended request is replacement of the representation.

HTTP PATCH is not a screenshot operation

HTTP method names matter when integrating APIs. ScreenshotNeo is a website screenshot API and MCP server, and its documented screenshot request uses GET with a URL to return an image or PDF; PATCH is not the method to use for taking a screenshot. Its API can capture a page as PNG, JPEG, WebP, or PDF, with request options for cases such as viewport, full-page capture, and waiting behavior.

Or skip the browser setup

For a screenshot request, call the GET endpoint rather than sending a PATCH request:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request parameters. Before capture, it accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each of those steps can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and each response identifies the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and MCP clients. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Specifications

The core method rules are in RFC 5789, PATCH Method for HTTP; current HTTP method semantics and idempotency are covered by RFC 9110, HTTP Semantics; and the JSON Patch document format is specified in RFC 6902, JavaScript Object Notation (JSON) Patch. These standards define protocol behavior, while an individual API’s documentation determines which resources, formats, and operations that API supports.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.