HTTP 226 IM Used

Quick reference

How delta encoding works

The concept: instead of transferring an entire 10MB resource when only 100KB changed, the server sends only the 100KB diff. The client applies the diff to its cached copy to reconstruct the new version. This is the same idea as software package updates or git diffs — only changes are transferred.

The client signals delta encoding support via the A-IM (Accept-Instance-Manipulations) request header, listing the diff algorithms it supports. It also sends If-None-Match with the ETag of its cached version to identify the base instance the diff should be computed from:

GET /data/large-config.json HTTP/1.1
A-IM: vcdiff, diffe, gzip
If-None-Match: "etag-v12"

If the server supports delta encoding and can compute a diff from the client’s specified base, it responds with 226:

HTTP/1.1 226 IM Used
ETag: "etag-v15"
IM: vcdiff
Delta-Base: "etag-v12"
Content-Type: application/vcdiff

[vcdiff binary delta data]

The client then applies the vcdiff delta to its cached etag-v12 version to produce etag-v15. If the client does not have the base version identified by Delta-Base, it must discard the delta and issue a fresh unconditional GET for the full resource.

Instance manipulation algorithms

RFC 3229 defines a registry of instance manipulation (IM) types. The most relevant for delta encoding:

VCDIFF is the most capable algorithm for binary delta encoding. It can efficiently diff arbitrary binary files, not just text. The vcdiff specification (RFC 3284) defines a compact binary format for representing the differences between two arbitrary byte sequences.

Why RFC 3229 was not adopted

Despite the bandwidth-saving potential, RFC 3229 saw almost no real-world adoption. Several factors explain this:

Complexity: Both clients and servers must implement the same diff algorithms. The client must maintain a cache of base instances to apply deltas to, and must handle the fallback case (no shared base) gracefully. This is significantly more complex than standard HTTP caching.

Server-side cost: Computing a diff on every response requires keeping old versions of resources server-side (to compute from) and running a diff algorithm on each request. For large, frequently-updated resources this can be expensive. Caching the diffs helps, but only for the specific base versions clients have.

CDN incompatibility: CDNs work by caching complete responses. Delta responses are specific to a particular client’s cached base version — they cannot be shared in a CDN cache across clients with different cached versions. This makes delta encoding incompatible with the CDN model that drives most of the web’s performance.

HTTP/2 and compression: HTTP/2 header compression (HPACK) and response compression (gzip/brotli) reduced the practical bandwidth savings that delta encoding was designed to provide, making the added complexity less justified.

Modern alternatives to delta encoding

ETag-based conditional GET (304 Not Modified): For resources that have not changed at all, conditional GET with If-None-Match returns 304 with no body — essentially a zero-byte response. For frequently-unchanged resources, this is more effective than delta encoding.

Efficient serialization formats: JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396) provide application-level delta formats for JSON APIs. Clients receive a patch document and apply it to their cached state. This works with standard HTTP 200 responses and is widely adopted in REST APIs.

Brotli compression: For text resources (JSON, HTML, CSS), Brotli compression achieves high compression ratios, reducing transfer sizes significantly without the complexity of delta encoding.

Change-data feeds: For resources that change frequently and need efficient client synchronization, event streaming (Server-Sent Events) or WebSockets deliver incremental changes as they occur rather than requiring the client to poll and receive deltas.

Frequently asked questions

What does HTTP 226 mean?

The server fulfilled the request using HTTP delta encoding (RFC 3229). The response body contains a diff (delta) rather than the full resource. The client must apply the diff to its cached base version to reconstruct the current resource. In practice, 226 is essentially never seen outside experimental implementations.

Will a browser display a 226 response correctly?

No. No mainstream browser implements RFC 3229 delta encoding. If a server returns 226 to a browser, the browser will not know how to apply the delta and the response will be unusable. Delta encoding via RFC 3229 is only viable in controlled environments where both client and server are custom implementations.

Is 226 the same as HTTP compression (gzip)?

No. gzip compression (indicated by Content-Encoding: gzip) reduces the size of the full response body. Delta encoding (226) sends only the differences between the current and cached version, which is a fundamentally different mechanism. gzip works on any response; delta encoding requires the client to have a specific cached base version.

What is the A-IM header?

A-IM stands for Accept-Instance-Manipulations. It is the request header used with RFC 3229 delta encoding, listing the diff algorithms the client supports (analogous to how Accept-Encoding lists compression algorithms). A server that receives an A-IM header and supports one of the listed algorithms may respond with 226 and a delta body.

Related guides

HTTP 200 OK · HTTP 304 Not Modified · HTTP 206 Partial Content

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 3229 §10.4.1. Human-readable guidance by ErrorLookup. · HTTP 226 quick reference →