HTTP 226 IM Used

Quick reference

What HTTP 226 means

The core idea behind 226 is bandwidth reduction. For large resources that change incrementally — software packages, large JSON datasets, firmware images — transmitting only the difference between the old version and the new version is far more efficient than sending the complete file. HTTP delta encoding is the mechanism for doing this at the HTTP protocol level.

The response code 226 tells the client: "The body I am returning is not the full resource — it is the result of applying an instance manipulation to your base version. Apply the transformation the IM header identifies and you will have the current state."

The word "instance" in RFC 3229 terminology refers to a specific version of a resource — what most engineers would call a resource version or cache entry. An "instance manipulation" is a function that takes one instance as input and produces a derived output. The canonical IM is a delta or binary diff, but RFC 3229 defines the mechanism generically to accommodate multiple transformation types.

226 is to delta encoding what 206 Partial Content is to range requests: a success code that signals the response body is not the complete representation of the resource, but a computed subset or transformation of it.

How HTTP delta encoding works

The delta encoding negotiation flow involves three request/response pairs and several new headers introduced by RFC 3229:

Step 1 — Client requests with A-IM and ETag

The client advertises delta encoding support via the A-IM request header, listing the instance manipulation algorithms it supports. It also sends an If-None-Match header with the ETag of its cached version to identify the base instance.

GET /data/largefile.json HTTP/1.1
Host: api.example.com
A-IM: vcdiff, diffe, gzip
If-None-Match: "etag-v42"

The A-IM value lists preferred algorithms in order of preference. vcdiff is an open binary diff format (RFC 3284). diffe is a Unix diff algorithm. gzip as an IM means "apply gzip compression to the delta itself."

Step 2 — Server responds with 226 and the delta

If the server has a delta between the client's cached version (identified by the ETag) and the current version, it returns 226 with the delta in the body and the IM header identifying the algorithm used. The Delta-Base header contains the ETag of the base instance the delta was computed from.

HTTP/1.1 226 IM Used
ETag: "etag-v47"
IM: vcdiff
Delta-Base: "etag-v42"
Content-Type: application/vcdiff
Content-Length: 1840

[binary vcdiff delta data]

The ETag on the response is the ETag of the new (current) version, not the base. The body is the vcdiff patch between version 42 and version 47.

Step 3 — Client applies the delta

The client takes its cached version (etag-v42), applies the vcdiff patch from the response body, and reconstructs version 47. It then updates its cache entry with the new content and the new ETag.

If the server does not have a delta for that base ETag — for example, if the base version is too old or delta computation was too expensive — it falls back to 200 with the full resource and the current ETag. The client handles this the same way as a normal 200 response.

Instance manipulation algorithms

RFC 3229 defines a registry of instance manipulation types. The IANA Instance Manipulation Registry contains the registered values. The most relevant are:

vcdiff — Binary diff format defined in RFC 3284 (VCDIFF Generic Differencing and Compression Data Format). Widely used in software update systems (Chrome uses it for extension updates, for example). Compact and efficient for arbitrary binary data.

diffe — Text diff based on the Unix diff algorithm. Useful for line-oriented text files. Less efficient than vcdiff for binary data.

gdiff — An older binary diff format, largely superseded by vcdiff.

gzip — When listed as an IM, indicates the delta (from whatever diff algorithm) is additionally gzip-compressed. Often paired: IM: vcdiff, gzip means the body is a gzip-compressed vcdiff delta.

identity — No transformation. A 226 with IM: identity is effectively the same as a 200 response. This is allowed but unusual.

Adoption and practical use

RFC 3229 was published in January 2002. More than two decades later, adoption remains minimal. No mainstream web browsers implement the A-IM request header. The HTTP/2 and HTTP/3 specifications did not incorporate delta encoding. Major CDNs and reverse proxies do not support 226 as a first-class feature.

The places where RFC 3229 delta encoding does see use are outside of the general web: software update distribution systems (patch delivery for large binary packages), machine-to-machine API synchronization for large datasets, and embedded systems that implement custom HTTP stacks with delta support for firmware updates.

If you encounter 226 in server logs or network traces and are not running a system specifically implementing RFC 3229, it likely indicates a misconfiguration or an error in a non-standard application layer. General-purpose HTTP clients and servers treat 226 as an unrecognized 2xx code and handle it as if it were 200, per RFC 9110's rule for unknown status codes in a known class.

The lack of adoption is not a design flaw in RFC 3229 — delta encoding genuinely reduces bandwidth for frequently-updated large resources. The gap is implementation cost: every client must implement the delta application logic, every server must maintain versioned instances and compute deltas on demand, and cache intermediaries must handle the Vary semantics correctly. The overhead was not worth it for most HTTP use cases when Content-Encoding gzip already handles most compression needs.

226 vs related status codes

FAQ

What does HTTP 226 IM Used mean?

226 means the server returned a delta (difference) between the client's cached version of a resource and the current version, rather than the full resource. The client must apply the delta algorithm identified in the IM response header to its cached copy to reconstruct the current state. Defined in RFC 3229.

What is HTTP delta encoding?

HTTP delta encoding is a bandwidth optimization technique where the server sends only the changes between an old and new version of a resource. The client advertises delta support via the A-IM request header and identifies its cached version via ETag. The server computes and returns the delta, responding with 226 and the IM header naming the algorithm used.

Is HTTP 226 widely supported?

No. RFC 3229 has extremely limited adoption. Mainstream browsers do not send the A-IM header. CDNs and proxies do not implement it. It sees use in specialized software update systems and machine-to-machine data sync, but not in general web traffic.

What is the difference between 226 and 304?

304 means the resource has not changed — the client uses its cached copy unchanged. 226 means the resource has changed, but the server is sending only the delta. With 304, the client's cache is current. With 226, the client must patch its cache using the delta in the response body.

Related resources

On this site: HTTP 200 OK · HTTP 206 Partial Content · HTTP 304 Not Modified · HTTP 207 Multi-Status · All 2xx success codes

Standards: RFC 3229 §10.4.1 — Delta Encoding in HTTP · RFC 3284 — VCDIFF Generic Differencing Format · IANA HTTP Status Code Registry · MDN Web Docs: 226