226 IM Used 2xx

What does 226 mean?

A 226 IM Used response means the server fulfilled a request for a resource, and the response represents the result of applying one or more instance manipulations to that resource — most notably, delta encoding, where instead of sending the full resource, the server sends only the difference (delta) between the version the client already has and the current version.

226 is, without much competition, one of the most obscure status codes in the entire HTTP registry. It comes from RFC 3229 ("Delta encoding in HTTP," 2002), an approach designed to reduce bandwidth for clients that periodically re-fetch resources that change incrementally (think: a frequently-updated document where only a small portion changes between fetches) — sending just the changed portion (a "delta") rather than the entire updated resource.

How a 226 behaves

• It implies the response body is a delta/diff, not the full resource — the client is expected to apply this delta to its existing cached copy to reconstruct the current version
• It requires the client to have a previous version to apply the delta to — without this, a delta is meaningless; the client needs the "before" to combine with the "delta" to get the "after"
• It's tied to specific, rarely-implemented negotiation mechanisms (A-IM request header, IM response header) for clients and servers to agree on delta encoding formats

Why it's almost never seen

Delta encoding addresses a real problem (re-fetching large, slowly-changing resources is wasteful), but the broader web ecosystem has largely solved this differently:

• Conditional requests + 304 handle the common case of "nothing changed, don't re-send anything" efficiently
• Granular APIs (e.g., returning only specific fields/objects that changed, via application-level design rather than HTTP-level delta encoding) address "partial update" needs in a way application developers find more tractable
• Compression (gzip, br) reduces transfer size for full resources significantly, often making the complexity of implementing delta encoding not worth the additional savings on top of compression

As a result, 226 and the delta-encoding mechanisms around it never achieved meaningful adoption, despite being a real, standardized part of HTTP.

Common scenarios (largely theoretical)

If you're building the API or website:

• You're extremely unlikely to need or encounter 226 in standard web/API development — application-level patterns (partial updates via API design, compression, conditional requests) address the underlying goals far more practically
• If working with specialized systems explicitly implementing RFC 3229 delta encoding (rare), 226 would be part of that system's normal operation

If you're calling an API:

• Essentially never relevant for typical REST/web APIs

If you're a website visitor:

• Not applicable

SEO implications

None — 226 has essentially no real-world presence in web content delivery.

FAQ

What is "delta encoding" in HTTP?

A mechanism (defined in RFC 3229) where, instead of sending a full updated resource, a server sends only the differences between a version the client already has and the current version — intended to save bandwidth for resources that change incrementally.

Why didn't delta encoding catch on?

Compression (gzip/br) already significantly reduces transfer sizes for full resources, conditional requests (304) handle "nothing changed" efficiently, and application-level API design (returning only changed fields/records) addresses partial-update needs more practically than a generic HTTP-level delta mechanism — making the additional complexity of implementing RFC 3229 not worth it for most use cases.

Will I ever encounter 226 in practice?

Almost certainly not, unless working with a specialized system explicitly built around RFC 3229 delta encoding, which is exceptionally rare in modern web/API development.

Is 226 deprecated?

It remains technically defined in the HTTP status code registry, but it's effectively unused in practice — not formally deprecated, but functionally obsolete due to lack of adoption.

What does "IM" stand for?

"Instance Manipulation" — referring to the transformation(s) applied to the resource (such as delta encoding) to produce the response.

Fun fact

226 is frequently cited (often by developers compiling "obscure HTTP status codes" lists) as perhaps the single least-encountered status code in the entire registry — it represents a genuinely thoughtful solution to a real bandwidth problem from the early 2000s that was simply overtaken by simpler, more broadly-applicable alternatives (compression, conditional requests, API design patterns) before it ever found meaningful real-world adoption.